3 ms·

But why? You even asked at the very beginning "I shouldn't accept just anything, right?" But why not? Like what is going to happen if someone uses a "non emoji?

But why? You even asked at the very beginning "I shouldn't accept just anything, right?" But why not? Like what is going to happen if someone uses a "non emoji?" Nothing. Nothing will happen. Well now you will tell at the person and tell them to use an emoji. But if you just accepted everything, it would just work. It would save you time and your users grief. My main question here is, how future proof is this?

Fraterkes 3y ago
Their vision for their tool is that you tag stuff with emoji instead of characters, an arbitrary, deliberate limitation. Should they adjust that just because of a Unicode implementation detail?
- padjo 3y ago
  I think the point is that there’s no need to go to such lengths to enforce it. They build the picker UI so most users will just pick an emoji using that. Sometimes it’s important to limit degrees of freedom with strict validation but in this case I’d wonder if a non emoji would really cause a problem.
- PointedDreams 3y ago
  I think that's all fine, but implementing this restriction comes at a cost of maintainability. I'd say a much more pragmatic solution would be to allow a maximum of a few characters on the backend (say 10, because unicode) and then restrict the input on the front-end. If someone is willing enough to put other characters in that field by submitting the API request themselves, so be it - but it's also completely reasonable to turn around and tell them the reason their views don't look correct is because they submitted invalid data. The reality is these users will be very few and far between, and as long as it doesn't pose a security risk there are very few benefits to strongly enforcing this limitation.
- makeitdouble 3y ago
  "what's an emoji" will also be different depending on the users, and while a service provider can just stand their ground on the whatever definition they want, that brings undue stress for the user. For instance try explaining to a user why :heart: is ok but not ♥
rahkiin 3y ago
I was thinking the same thing. Why not limit input through the api to 1 grapheme if misuse is the worry? Or why accept all emoji and not a sensible sublist like Notion?
- Kerrick 3y ago
  The end of The article describes how 1 grapheme is a mostly good solution except that not all emoji work with the JS used to validate that, and the JS to validate it isn’t available in Firefox.
  - rahkiin 3y ago
    But this would be a back-end check, not a front-end check. Why would lack of support in Firefox matter?

Fraterkes 3y ago

Their vision for their tool is that you tag stuff with emoji instead of characters, an arbitrary, deliberate limitation. Should they adjust that just because of a Unicode implementation detail?

padjo 3y ago
I think the point is that there’s no need to go to such lengths to enforce it. They build the picker UI so most users will just pick an emoji using that. Sometimes it’s important to limit degrees of freedom with strict validation but in this case I’d wonder if a non emoji would really cause a problem.
PointedDreams 3y ago
I think that's all fine, but implementing this restriction comes at a cost of maintainability. I'd say a much more pragmatic solution would be to allow a maximum of a few characters on the backend (say 10, because unicode) and then restrict the input on the front-end. If someone is willing enough to put other characters in that field by submitting the API request themselves, so be it - but it's also completely reasonable to turn around and tell them the reason their views don't look correct is because they submitted invalid data. The reality is these users will be very few and far between, and as long as it doesn't pose a security risk there are very few benefits to strongly enforcing this limitation.
makeitdouble 3y ago
"what's an emoji" will also be different depending on the users, and while a service provider can just stand their ground on the whatever definition they want, that brings undue stress for the user. For instance try explaining to a user why :heart: is ok but not ♥

rahkiin 3y ago

I was thinking the same thing. Why not limit input through the api to 1 grapheme if misuse is the worry? Or why accept all emoji and not a sensible sublist like Notion?

Kerrick 3y ago
The end of The article describes how 1 grapheme is a mostly good solution except that not all emoji work with the JS used to validate that, and the JS to validate it isn’t available in Firefox.
- rahkiin 3y ago
  But this would be a back-end check, not a front-end check. Why would lack of support in Firefox matter?