With Ember octane and in combination with recent developments such as ember-auto-import one major issue with ember is greatly fading away. Namely the integration of existing JS libraries in combination with making ember itself use standard javascript language features, most prominent to highlight are native classes over ember object.
That also means it’s time to better connect ember with existing solutions rather than ember-breed them ourselves, as this is simply maintenance overhead and catching up on feature parity with competitive solutions. In this article I want to explain what are the approaches to these solutions, what might be a mind-shift for you and will share my experiences about recent developments.

This is part 2b of the from Figma to Ember to Storybook series, which I make sure can be read on its own.

The example at hand will be integrating token manager tools with ember. The original problem is a the need to store design tokens in a format, process them and have them at available in ember. I defined token manager tools as a store of DTO files (usually yaml or json) describing tokens and run a build step to export those tokens into various formats (e.g. css, sass, less, ios or android).
I will be explaining approaches in isolation and conclude both of them afterwards.

1. Approach: ember-makeup

My fantastic co-worker Jan Buschtoens was working on such a solution for ember named ember-makeup. Tokens are defined in yaml, then exported into css-modules and come with directives to consume them. Some constraints ember-makeup defined to work with tokens:

• Base tokens (such as color definitions) will only be processed but never will be consumable by the developer
• Component tokens reference base tokens and are consumable by the developer
• Component tokens can appear in multiple context (e.g. light or dark) and ember-makeup connects them seemingly

Since this was my first experience with token manager tools these constraints kinda stick with me… for the good I must say as they are still applicable.

ember-makup operates primarily at the “build-layer” of ember, with plugins for broccoli, postcss and css-modules. The last release is still alpha and not everything was working enjoyable as planned, such as selecting a context within a theme, which is totally fair. The rise and awareness of other token manager tools lead to a suspension of this project. That said, if you are looking for code-as-a-teacher, I can recommend this project for intermediate/advanced ember learners!

2. Approach: Theo? Style Dictionary? Theemo!

Other token manager tools draw attention. I looked into Theo and Style Dictionary. I liked the format for tokens of the latter more and decided to use Style Dictionary. Ok… but I already had my tokens in Figma and really didn’t wanted to manually transfer them over and over again, especially if they change, Figma shall be the source of truth here. So I started writing scripts that sync from Figma to Style Dictionary… which turned into Theemo. With theemo it is also possible to keep the constraints when working with tokens as learned with ember-makeup. Theemo was built to enable a smarter workflow on top of existing tools: Figma, Style Dictionary and frontend frameworks/libraries. It takes input from Figma and generates configurable outputs that are input to your application.

Until here, no ember was involved, which is the final step now. Imagine Theemo changes a file that your app is using, ember-cli wouldn’t know that and would do nothing. However, we as ember developers are used that the page refreshes whenever we do a change to a file we use. That is the purpose of ember-theemo a thin layer connecting theemo and ember together, glue code as little as needed. All ember-theemo does:

• Finds themes you’ve installed with yarn/npm
• Let’s you configure which one you want to use as default
• Watches respective files for changes

Expect more precise control to come how ember-theemo will handle your themes as this is an unknown field and needs some hands-on experience. However the workflow ember-theemo enables:

• Use theemo as intended, theemo doesn’t even know ember-theemo is in use
• Still use the one-command-magic for theemo to generate themes from Figma

Conclusion

There is two approaches with an evolution from the first to the second, which I’m overall pretty happy with. If you are caught in the mindset, that ember has a need for its own solution that is recreating an already existing one instead of find a common ground and ways to collaborate. Here is some food for thoughts:

• Is there already an agnostic solution? Write an ember “adapter” to it, a thin layer is mostly enough
• The thing you are building – can it done in an agnostic way or is it for ember only? An ember-incubator solution is still a good start if you build it with the mindset of stripping the ember part off.
• Interfaces between your thing and other ecosystem will become more important, treat them accordingly.

Benefits (some):

• Clear separation between ember and your thing – both can be developed in isolation
• You only have to maintain the ember glue code (most likely a thin layer)
• You share feature development with other ecosystems instead of recreating them
• More free time for you 🙂
• You learn more when thinking about other integrations – especially interfaces 😉

There is a very popular example in the ember ecosystem that is built for ember where there is a agnostic solution available. At least nowadays, keep in mind it was truly a different situation when it was developed. That is ember-cli-addon-docs and storybook. Ember maintains its own solution, which nowadays has become a mainteneance burden of keeping things going but is constraining further developments. On the other hand is storybook with interfaces to connect with respective javascript ecosystems around major frontend framework/libraries (even ember maintains it’s thin layer here – expect more from it in the next post).

ember-makeup could have turned into a similar-to-maintain project as ember-cli-addon-docs, which why it was wise to suspend it and re-orientate for wider, generic and agnostic solutions. These have been found with Style Dictionary, enhanced with theemo and made available to ember with ember-theemo. I am happy with the direction this development took.

Reference: hokulea@91d9df0 – Hokulea project with both approaches

-gossi