Readers' Question - "When will we be able to use decorators in Ember apps?"

@pzuraq wrote:

Hello once again to Readers’ Questions, presented by the Ember.js Times.

Today we have a question asked by jj:

When and how will we be able to use decorators in Ember apps?

The short answer is you can actually use decorators with Ember right now!

Last year we merged an RFC that locked in the behavior of using native class syntax with EmberObject, which was a precursor to being able to stably use experimental technologies like decorators and class fields. Since then, the ember-decorators project has been continuing to refine a set of decorators which will hopefully one day actually become part of Ember core (following the path laid out by ember-native-dom-helpers for testing out and refining new expansions to the Ember API).

You can check out this blog post for more details on using decorators along with native ES class syntax in Ember today, and you can see the latest status on the implementation of the ES Class RFC on the Ember Status Board.

Should I use decorators in my app/addon?

Now, just because you can use experimental stage 2/3 technologies doesn’t necessarily mean you should. What is the current state of these decorators and native class syntax? Are they production ready, or bleeding edge? What is the recommended path?

There are two separate considerations here - the stability of the language features themeselves, and the performance and readibility of the polyfills for the features.

Syntax Stability

If you are concerned with stability, class fields and decorators still haven’t made it all the way through the TC39 process (Fields are currently stage 3, decorators are stage 2), which means they still could change significantly. There was even a recent counter-proposal which was put forward that completely removed the concept of class fields, so even stage 3 proposals can be questioned and potentially changed significantly.

Assuming that there aren’t massive changes to the fields/decorators syntax, however, the ember-decorators project is dedicated to providing a stable API as the spec evolves. We haven’t seen too much churn between versions, and are expecting to be able to update from the Stage 1 decorators transform to the Stage 2 transform as soon as Babel releases it, without any breaking changes.

Performance and Debugability

If you’re okay with using cutting edge technology, the other major concerns are performance and debug-ability.

On the performance side of things, the current Stage 1 Babel transforms for decorators are not ideal because the code to decorate classes gets included in each individual Javascript module which uses decorators. This is not that much code by itself, but in large apps with many hundreds or thousands of collective modules it could add up quickly. With that in mind, apps and addons that are that are size-sensitive should avoid using decorators for the time being.

On the debug-ability side, class fields and decorators produce some gnarly code - if you’re familiar with the output of the async/await transform, it’s probably on the same level of complexity. It is definitely possible to debug and find your way around the output once you get a feel for it, but like all transpiled code it can be confusing, especially for someone who hasn’t seen it before.

TL;DR

Class fields and decorators are still experimental technologies in Javascript, but the ember-decorators project is dedicated to providing as much stability as possible as they change through the TC39 process. You can use the current transforms and decorators as far back as Ember 1, but if you are concerned with stability or performance you should probably wait until they move forward.

Posts: 6

Participants: 4

Read full topic