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.