Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intent to RFC: Deprecate EmberObject #535

Closed
pzuraq opened this issue Aug 30, 2019 · 2 comments
Closed

Intent to RFC: Deprecate EmberObject #535

pzuraq opened this issue Aug 30, 2019 · 2 comments
Labels
Seeking Co-author T-deprecation T-framework RFCs that impact the ember.js library

Comments

@pzuraq
Copy link
Contributor

pzuraq commented Aug 30, 2019

  • Proposed Target: Ember v5.0.0
  • Alternative: Native Classes

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:

  1. 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.
  2. 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.
  3. 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.

@locks locks added T-deprecation T-framework RFCs that impact the ember.js library labels Sep 2, 2019
@locks locks added this to Deprecations in Deprecation Candidates Sep 2, 2019
@pzuraq pzuraq changed the title Pre-RFC: Deprecate EmberObject Intent to RFC: Deprecate EmberObject Oct 8, 2019
@locks locks moved this from Deprecations to Reviewed in Deprecation Candidates Dec 7, 2020
@wagenet
Copy link
Member

wagenet commented Jul 23, 2022

Leaving this open since it's high priority. We should fast-track an RFC for this.

@wagenet
Copy link
Member

wagenet commented Jul 29, 2022

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!

@wagenet wagenet closed this as completed Jul 29, 2022
Deprecation Candidates automation moved this from Reviewed to Finished Jul 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Seeking Co-author T-deprecation T-framework RFCs that impact the ember.js library
Projects
No open projects
Development

No branches or pull requests

3 participants