You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EmberObject and the Ember Object model have served this community well for a long time, but with native syntax now fully supported in Ember applications, it no longer makes sense to continue shipping a full class model to every user, and the maintenance burden for it is quite large. Removing the object model from the framework will make apps lighter, and make it easier for us to maintain at the same time.
Migration Path
There are a few different aspects of this migration:
Migrating Components. Classic Components are inextricably tied to the object model, so it's not possible for us to migrate them directly. Instead, users will have to rewrite their components to Glimmer Components. This means that EmberObject can only be removed after Classic Components have been deprecated and removed as well.
Migrating framework classes. Route, Controller, Service, and Helper all extend from EmberObject currently. This pre-RFC proposes that rather than provide alternatives, like we do for components, we instead deprecate all of the methods that these classes inherit from EmberObject. For instance, Route.extend() would be deprecated, and this.get() on all of these classes. The base functionality of each class would be preserved, and it would be possible for users to migrate in place, without having to adopt a new base class.
Utility classes (classes that don't extend from a framework object) need to be converted to native classes in general, and shouldn't extend from EmberObject at all. We should create a conversion guide specifically for these.
Deprecation Timeline
The object model is deeply embedded in Ember and in the ecosystem, so it will take some time for users to migrate. That is why this pre-RFC proposes that we push out the deprecation until Ember v5.0.0 at the earliest. This will give users time to migrate to the new idioms, and will ideally give us plenty of breathing room in this migration.
The text was updated successfully, but these errors were encountered:
I believe this falls under the umbrella of #832. I'm going to close this issue to push any discussion there. Despite being closed, we will certainly use this issue for reference and to inform the future RFC. Thanks @pzuraq!
EmberObject
and the Ember Object model have served this community well for a long time, but with native syntax now fully supported in Ember applications, it no longer makes sense to continue shipping a full class model to every user, and the maintenance burden for it is quite large. Removing the object model from the framework will make apps lighter, and make it easier for us to maintain at the same time.Migration Path
There are a few different aspects of this migration:
EmberObject
can only be removed after Classic Components have been deprecated and removed as well.Route
,Controller
,Service
, andHelper
all extend fromEmberObject
currently. This pre-RFC proposes that rather than provide alternatives, like we do for components, we instead deprecate all of the methods that these classes inherit fromEmberObject
. For instance,Route.extend()
would be deprecated, andthis.get()
on all of these classes. The base functionality of each class would be preserved, and it would be possible for users to migrate in place, without having to adopt a new base class.EmberObject
at all. We should create a conversion guide specifically for these.Deprecation Timeline
The object model is deeply embedded in Ember and in the ecosystem, so it will take some time for users to migrate. That is why this pre-RFC proposes that we push out the deprecation until Ember v5.0.0 at the earliest. This will give users time to migrate to the new idioms, and will ideally give us plenty of breathing room in this migration.
The text was updated successfully, but these errors were encountered: