muan / emojilib

Emoji keyword library.
https://unpkg.com/emojilib@latest
MIT License
1.67k stars 296 forks source link

First entry for some emoji is slug, some are not #228

Closed erquhart closed 4 months ago

erquhart commented 4 months ago

I'm trying to reliably match an emoji slug to the list, but this isn't currently possible.

Most use a slug as the first entry in the list: https://github.com/muan/emojilib/blob/0e7aca39ae468df1012cc6ff2ef47a77cd55fdd1/dist/emoji-en-US.json#L2-L10

But some use spaces instead of underscore, so they can't be matched by slug: https://github.com/muan/emojilib/blob/0e7aca39ae468df1012cc6ff2ef47a77cd55fdd1/dist/emoji-en-US.json#L12998-L13003

Is this intentional, or is it too late to fix?

muan commented 4 months ago

The space separated one I think might only be the newer ones since the slug responsibility was moved over to https://github.com/muan/unicode-emoji-json since 3.x. See "slug" field.

However, I wouldn't say that is "reliable". The Unicode emoji spec itself changes name of emoji every now and then as well. For example Gun was changed to Water Gun between versions. If you want something reliable it might either have to be custom maintained yourself or follow one of those platform specific short codes from GitHub, Slack, Discord, and the likes.

It's not too late to fix but there isn't a standardized way for this yet (#194).

If I were to make a decision today I'd lean towards using space separated emoji names as keywords.

erquhart commented 4 months ago

Thanks for the response. I'd expect a primary use case to be storing an emoji reference as a string in a db, whether standalone or in markdown. In either case a slug-style string is pretty much the norm.

At any rate, I've switched to mapping directly against unicode-emoji-json to address this.