Research possible front-end dev patterns and expectations

[axelpale]

How front-end developers would like to use the API programmatically? Explore the options, wishes and expectations.

[axelpale]

I asked a front-end and React developer @juissi999 how he would imagine the API to behave. He had no prior knowledge of openmoji internals or structure. He gave this interesting three-part React & ES6 flavoured pseudo-code example:

import 'openmoji'
// or
import { E1F600 } from 'openmoji'
// or
import grin from 'openmoji/1F600'

const Emoji = () => {
  return (<img src={ openmoji.1F600 }></img>)
}

In package.json the package would be listed as a dependency. Updating the dependency would update the emojis in the app:

$ npm install openmoji
---
dependencies: {
  openmoji: "1.0.0"
}

He also made notion about how the import of the grinning face emoji should affect the build dir and the JS bundle. The emojis should not be bundled inline but copied under images/ or such dir.

$ cd build && ls
images/
index.html    1 kB
bundle.js     300 kB
(and NOT like below!)
$ cd build && ls
index.html    1 kB
bundle.js     4 MB

I think such straightforward usage is an attractive feat. Maybe in future yet another module openmoji-react could provide such lightweight and front-end friendly functionality.

[axelpale]

This article discusses dynamic imports that could make @juissi999's imagined API reality: https://medium.com/front-end-weekly/webpack-and-dynamic-imports-doing-it-right-72549ff49234

[axelpale]

See openmoji-picker for a sketchy real-world usage example.

[axelpale]

Here is another import technique when using webpack with file-loader:

const urlToImage = require('openmoji-sprites/docs/png72/animals-nature-00.png')