Single JSON file containing shortcodes

This is a small feature request, and I totally understand if it’s out-of-scope for the project.

As of emojibase-data v6, the data.json file and shortcode file need to be stitched together to have both the shortcodes and emoji data in the same file (#64).

However, for my own use case (https://github.com/nolanlawson/emoji-picker-element/issues/47), having a single file was a nice convenience. By default, the library just fetches the JSON from jsdelivr (this is designed for folks not using a build step). Switching to multiple files is possible, but pushes complexity either to me or my consumers (or both).

To ease the process of upgrading from v5 to v6, perhaps a new JSON file could be added – call it data-with-shortcodes.json – which just includes the default Emojibase shortcodes? This would provide the most direct upgrade path to v6, while also allowing users to stitch together the files themselves if they prefer some other shortcode set.

I can only speak for my own library, but this would definitely help with the upgrade process. 🙂 Thanks for creating emojibase!

[nolanlawson]

Thanks for your response. Using LocalStorage/SessionStorage is a reasonable approach, but I’m avoiding it because 1) it’s synchronous, 2) accessing it means reading the entire emoji database into memory, and 3) accessing it also means running JSON.parse on the entire database. My technique is to use IndexedDB, so that all the querying can be done asynchronously, avoiding these costs on subsequent page load. Some details here.

I agree that in HTTP/2 having one additional network request is not a huge deal. I may look into caching the two ETags separately, or writing a small npm package to stitch the files together and publish the result.

Thanks again for creating emojibase! I appreciate all the hard work you’ve put into this, and dealing with users with very meticulous demands. 🙂

[milesj]

Yeah sorry, I have no plans of merging shortcodes back into the primary dataset for 2 reasons.

1. The old shortcodes were the biggest complaint about emojibase, as they did not align with GitHub/Slack/Discord – all 3 of which are different from each other. I no longer want to force certain shortcodes on the consumer, as they should choose which preset they want.
2. Removing shortcodes reduced all dataset file sizes by quite a lot.

I’d argue that multiple HTTP requests is a non-issue, as the browser/fetch is rarely the bottleneck. I avoid subsequent requests by caching the response in local/session storage (https://github.com/milesj/emojibase/blob/master/packages/core/src/fetchFromCDN.ts#L46). I would suggest doing something similar, coupled with your ETag implementation, and maybe supporting a shortcodesSource setting.