ELI5: Upcoming Developments in Ember.js

By: Rowan Krishnan

ELI5: Upcoming Developments in Ember.js

As a newcomer to Ember in the past few months, it’s been fascinating to not only learn how to build applications with a great JS framework, but also to gain insight into how a massive and popular open source project grows and absorbs new ideas. Although I’m probably a little bit biased at this point, I believe Ember does a better job than most at managing and encouraging this process.

The primary channel for discussion of introducing new features into Ember is the public RFC repository on GitHub. RFCs, which stand for ‘Request For Comment’, are pull requests in which any developer can outline a feature specification and open the floor for comments and criticism. This is what true open source looks like, and the success of the RFC repo represents to me the best aspects of the Ember community.

All of that being said, it can certainly be a little intimidating for someone new to the framework to dive right in and catch up on the most significant RFCs being discussed. So I decided to do a little write up that made that easier.

Here are the three RFCs that have provoked the most discussion, and perhaps demonstrate what the future of Ember looks like:

Module Unification

Create a unified pattern for organizing and naming modules in Ember projects that is deterministic, extensible, and ergonomic.

This seems like the best one to start with, since it’s the one most likely to affect all users of Ember and dramatically impact daily use of the framework. In short, this RFC aims to provide an improved ergonomic directory structure for all new Ember projects.

Why? Well, there are unfortunately a few too many deficiencies with the current system of organizing Ember modules.

  • Developers have to decide between using the pod or classic app structure.
  • Addons are directly mixed into the codebase and therefore present opportunities for name collision.
  • Module resolution rules are esoteric and inefficient.

The proposed solution to these problems does a major refactor of default Ember app structure. Replacing app at the top level is a new directory called src which can contain several subdirectories (data, init, ui, utils, and services). Here’s an example of what this could look like in a blogging application, as shown in the RFC:

src
  data
    models
      author.js
      comment
        adapter.js
        model.js
        serializer.js
      post
        adapter.js
        model.js
        serializer.js
    transforms
      date.js
  init
    initializers
      i18n.js
    instance-initializers
      auth.js
  services
    auth.js
  ui
    components
      capitalize.js
      date-picker
        component.js
        template.hbs
      list-paginator
        component.js
        template.hbs
        paginator-control
          component.js
          template.hbs
    partials
      footer.hbs
    routes
      application
        template.hbs
      index
        template.hbs
        route.js
        controller.js
      posts
        -components
          capitalize.js
          titleize.js
          -utils
            strings.js
        post
          -components
            post-viewer
              component.js
              template.hbs
          edit
            -components
              post-editor
                post-editor-button
                  component.js
                  template.hbs
                calculate-post-title.js
                component.js
                template.hbs
            route.js
            template.hbs
          route.js
          template.hbs
        route.js
        template.hbs
    styles
      app.scss
    index.html
  utils
    md5.js
  main.js
  router.js

There are a couple of examples of this in action; namely the Ghost Admin and Travis Client. Rob Jackson has also done a fantastic job in releasing a tool that allows us to migrate our apps over to this new structure.

The RFC goes into a great amount of detail regarding other changes that will need to take place, such as renaming and reorganizing modules, and a refactor of the Ember Resolver. You can read the whole thing here.

Testing Unification

The goal of this RFC is to unify the concepts amongst the various types of test (acceptance, integration, and unit) and provide a single common structure to tests.

Look, most of us don’t really love writing tests. It’s okay to admit it. But as Rob Jackson explains in his RFC, Ember’s testing story is coming together quite nicely, and it’s never been easier to write comprehensive tests across all the various pieces of your app (routes, components, templates, etc). One of the best aspects of Ember being a “full featured” framework is that it comes packaged with all the libraries and tools you’d need to write great tests, with as little friction as possible.

The only persisting problem is that these tests look and function quite different from one another. Specifically, they handle things like asynchronous requests differently and use unique sets of helpers. This RFC seeks to “unify” the three types of tests - acceptance, integration, and unit - by introducing new syntax to handle asynchronous test actions, and establishing a set of test helpers that would be shared across the three types of tests.

Like the Module Unification RFC, this one goes into a great amount of detail that eclipses the scope of an ELI5. I highly recommend checking it out the full spec if you’re interested in the future of testing.

Routable Components

Eliminates Controllers.

Ah, yes. The Holy Grail of RFCs. The future of Ember. The promised land.

In all seriousness, routable components are a pretty big deal, and received an appropriately large reaction when first presented at EmberConf 2015 by Tom Dale & Yehuda Katz. It’s been a long time since then, and if you’ve been following along, you might need a little refresher on how they are intended to work.

As the description above concisely states, routable components essentially mean the death and deprecation of controllers. This is a good thing. For many months now, controllers have been a key point of confusion for new developers, and stick out as a remnant of pre-2.0 Ember. One of the biggest complaints about the framework in the early years was that the architectural pattern was far too complicated (“MVC? MVVM? What’s the difference between a view and a controller?”). Ember continuing to simplify and mature these patterns is great news.

Routable components hope to replace controllers by absorbing the few functional responsibilities that they still have, such as query parameters and setting a route’s model on the template or top-level component. Discussing the implementation for these changes, however, is a tricky subject due to the length of time passed since the concept of routable components was first introduced. Original proposals included removing older model hooks (such as beforeModel and afterModel) and introducing a new, automatically invoked hook called “attributes”, that would allow a route to specify the positional and query parameters to be passed into a rendered component.