EmberObject
, there are a number of caveats and limitations you need to be aware of. For today, these caveats and limitations apply to any classes which extend directly from EmberObject
, or which extend classes which themselves extend EmberObject
:Component
– meaning classic Ember components, which imported from @ember/component
, not Glimmer components which are imported from @glimmer/component
and do not extend the EmberObject
base class.Controller
Helper
– note that this applies only to the class form. Function-based helpers do not involve the EmberObject
base class.Route
Router
Service
Model
classEmberObject
, and it has the most caveats and limitations.EmberObject
base class dependency, but that will not happen till at least the next major version of Ember, and these guides will be updated when that happens..extend({ ... })
syntax, regardless of whether there is a named mixin involved, you are dealing with Ember's legacy mixin system. This in turn means that you are dealing with the parts of Ember which TypeScript is least able to handle well.this
in actions hashes, computed properties, etc. That in turn often leads to problems with self-referential this
: TypeScript simply cannot figure out how to stop recursing through the definitions of the type.EmberObject
EmberObject
base class eliminate any use of EmberObject
-specific API and convert to standalone class, with no base class at all. You can follow the ember-classic-decorator workflow to eliminate the base class—switching from init
to constructor
, getting rid of uses of methods like this.set
and this.get
in favor of using standalone set
and get
, and so on.EmberObject
-descended classesEmberObject
cannot follow the exact same path. However, as long as you are using native class syntax, all of these (Component
, Controller
, Helper
, etc.) work nicely and safely with TypeScript. In each of these cases, the same caveats apply as with EmberObject
itself, and you should follow the ember-classic-decorator workflow with them as well if you are converting an existing app or addon. However, because these base classes themselves descend from EmberObject
, you will not be able to remove the base classes as you can with your own classes which descend directly from EmberObject
. Instead, you will continue to extend from the Ember base classes: