Working in an Ember codebase from a designer point of view

We’ve been actively working with Ember for quite a few weeks now. We’ve posted two Ember-themed posts so far:

• the first one about getting to grips with Ember
• a second one where we talked about the abstraction of a button component.

This post, the last one for now in this “Ember series” is about some general topics about dealing with an Ember codebase from a designer’s point of view. We cover Ember addons, codemods and translations.

Addons are super easy

Creating an ember addon is so easy it is almost criminal.

For a long time I avoided creating an Ember addon because I thought it was going to be complicated. The reason that I thought this was going to be the case was the overly complex folder structure.

It turns out that there is a reason behind this overly complex folder structure, and that is of course “convention over configuration” and predictability.

If Ember knows exactly which folders there are, it can combine easily one codebase with another.

To try out the addons functionality I created a simple UI addon with 6 components called ember-jui. The structure looks like this:

.
|-- components
|   |-- alert.hbs
|   |-- alert.js
|   |-- avatar.hbs
|   |-- avatar.js
|   | (...not all components listed for brevity)
`-- styles
    `-- ember-jui.css

I publish this package to npm, and then loaded it in another app by installing the package:

npm i -d ember-jui

And as it turns out, the components were available immediately. Even the styles got loaded, without any configuration.

That’s awesome – albeit a little dangerous from a CSS perspective.

Codemods example: Angled bracket syntax vs classic syntax

Next, let’s talk about codemods. We are working on an application that was built quite some time ago. Not that long ago, but still.

Ember posits itself as the “together framework”, the idea is that everyone moves to the latest Ember release as soon as it becomes available. Ember does a release every 6 weeks, and developers are supposed to move with Ember.

As it goes in software not every part of the codebase is migrated to the latest way to do things in Ember.

But the good news is that Ember provides some tools to migrate to the newer way of doing things. These tools come in the form of codemods, which are basically scripts that automatically turn one type of code into another.

The codemod that I was particularly interested in for our designer-type work is called ember-angle-brackets-codemod, which transforms classic style component syntax to new style Octane syntax.

Here’s a simple example showing the old syntax:

{{#ui/button text="Click me"}}

Running it through the codemod will change this to:

<Ui::Button @text="Click me" />

These codemods can help to migrate a project to the newer Octane Syntax.

If you are interested in the background behind the topic of codemods, look into Sophia Wang’s talk AST: The secret weapon to transform a codebase.

Translations

Let’s talk a bit about translations.

In a Belgian context, your app is likely to be multilingual. This means that some content will be wrapped into translation strings, For examples say a button that says “Hello”, you have to write code like this:

<Button>{{ t 'hello' }}</Button>

"hello": "hallo"

Instead of the much simpler:

<Button>Hello</Button>

Currently, our app is only in Dutch, but we are still required to use translation strings by management.

We can temporarily disable linting though, by using the following:

{{!-- template-lint-disable no-bare-strings  --}}
<Button>Hello</Button>
{{!-- template-lint-enable no-bare-strings  --}}

In reality you would probably use this to skip linting on a whole template instead of a single component. I have to experiment more with this, but this can help to make parts of the app that are not part of the production environment (e.g. a styleguide) to not have unnecessary translations.

Generally speaking…

Since we dediced to embrace the modern Javascript frameworks as a deliverable target I’ve been learning a lot. This post was written when I was deep in Ember-land, now for we are moving into Angular-space for a new project. It’s interesting to compare the frameworks.

Conceptually, they are all alike, but they do things differently, sometimes in subtle ways. I’ve grown to like Ember, but my favorite is still Svelte. I can’t wait to be asked to do a project with that awesome little framework.