3 ms·
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
by 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 agoI 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 agoI 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 ♥