#EmberJS2019

EmberJS2019.md

As a front-end developer that started our as a designer, building highly polished and accessible UI components that also has a great developer experience is really imporant to me. Ember has been a powerful tool to accomplish this and Octane has made huge improvements to the overall quality of the code.

But, this wouldn't be a Ember 2019 roadmap blog post if there weren't a desire for improvement.

1. Components

When I design a new component I mock up the visual and UX design to make sure it will look good, function well, and be fully accessible. Part of that design process is figuring out the UX for the developer. I like to start with the desired invocation API and work my way backwards to the implementation. However, when you start building really complex interactive components you quickly run into limitations with Ember.

For example, if you were to try to re-implement the native select in Ember with custom <Select> and <Option> components you would quickly run into walls. Take this hypothetical markup:

<Select>
  <Option @value="any">
    <img src"" /> {{t "state.any"}}
  </Option>
  <Divider />
  <Option @value="pending" @disabled={{noPending}}>
    <img src"" /> {{t "state.pending"}}
  </Option>
  <Option @value="active" @disabled={{noActive}}>
    <img src"" /> {{t "state.active"}}
  </Option>
  <Option @value="pending" @disabled={{noPast}}>
    <img src"" /> {{t "state.past"}}
  </Option>
  {{#if (feature-flag "paused")}}
    <Option @value="paused" @disabled={{noPaused}}>
      <img src"" /> {{t "state.paused"}}
    </Option>
  {{/if}}
</Select>

Implementing this in Ember is really hard. You quickly run into a multitude of problems that arsies from:

• Components don't have access to their block contents so rendering the select's label is complicated and workarounds are slow
• Parent components don't know their children so keyboard navigation and filtering is painful
• Children can "register" with their parent, but won't necessarily know the order they appear in the DOM

But at the same time I believe that this data structure do belong in the template. Using javascript to assembling custom object structures that describe the DOM I want built instead of doing so in the template is frustrating. But we have gotten so used to doing some of our template logic in javascript that we don't even notice it any more.

Ember needs a way for a component to have direct knowledge of its children. In React you can access a components children via props.children, we need something similar. Maybe the block content for a component doesn't even get rendered, but is instead used only to decribe a data structure that can then be rendeded however the component wants.

2. File system layout

Using the classic file system layout on a large Ember app can result in a lot of searching for the matching files, but switching to a pods layout, a beta feature, brings fears of a potential massive amount of code debt in the future. Given that module unification appears to be dead, the Ember team needs to be clearer about where they want to end up with the file system layout, and how current applications can build their apps in as future-proof a way as possible.

Is it worth switching to pods? It co-locating css files and translation files a good idea? This is the one area where Ember has failed to set a clear convention and apps are starting to chart their own individual course.

3. ...attibutes on multiple elements

When building complex forms you will inevitably build your own <Input> component that wraps a traditional input. The markup may look something like this:

<div class="Input" ...attributes>
  <input value={{@value}} />
</div>

The problem arsises from some of the ...attributes values belonging to the input, and some to the wrapper element. Having control over which attributes goes where would enable us to finally stop turning every input attribute into an argument.

4. AST Transform docs

AST transforms are great and provide a solution to a ton of problems, but as far as I can tell, is 100% undocumented. This is possibly because it is a private feature, but that isn't 100% clear to me either because every serious addon seems to be doing a transform of some kind.

The best way I found to learn how to write an AST transform is to use Ember Observer to search for addons that also use it, and then read their code. This isn't great. For such a useful feature I would hope that it could become a public API and get a full suite of documentation.