EmberData | deprecate Store extends EmberObject #1026
Conversation
runspired
added
T-ember-data
Co-authored-by: MrChocolatine <[email protected]>
runspired
added
S-Exploring
|
discussed in EmberData meeting, moving to FCP |
|
This seems good to me. I agree with the strategy of using a single flag. One detail to remember: I think it's important that the single deprecation is visible at runtime and not just a build-time deprecation. |
| const app = new EmberApp(defaults, { | ||
| emberData: { | ||
| deprecations: { | ||
| DEPRECATE_STORE_EXTENDS_EMBER_OBJECT: false | ||
| } | ||
| } | ||
| }); |
There was a problem hiding this comment.
We've had a bit of a conversation on this in RFC review, I don't know if I'm overthining things but have we considered any of the negative aspects of introducing a new way to turn off deprecations like this?
i.e. we recently rolled out the deprecation for the implicit root model which requires you to update an optional feature to turn off the deprecation.
I feel like having two places to explain and document might get a bit strange, but I don't know if I'm over-indexing on how bad that would be 🤔
I'm also concerned that that introducing things like this into the ember-cli-build file doesn't feel very modern in terms of the modern tooling we're working on (Embroider, Vite) and I think the more natural way to achieve the desired outcome would be to either change the import location (as mentioned in the alternatives) or changing the thing that is imported e.g. import { NewStore as Store } from '@ember-data/store'
On that point what does not chosen as this is too minimal a change mean? 😂
There was a problem hiding this comment.
have we considered any of the negative aspects of introducing a new way to turn off deprecations like this?
This is in fact not a new way! This has been the way to resolve deprecations and remove associated code in EmberData for a few years now. This docs for this are here: https://api.emberjs.com/ember-data/release/modules/@ember-data%2Fdeprecations
I feel like having two places to explain and document might get a bit strange, but I don't know if I'm over-indexing on how bad that would be 🤔
EmberData/WarpDrive is not ember-source and its pretty hard for us to piggy back on ember-source infra, especially without introducing accidental coupling we don't want.
I'm also concerned that that introducing things like this into the ember-cli-build file doesn't feel very modern in terms of the modern tooling we're working on (Embroider, Vite)
Just the opposite! Our config story was already driven by macros, and in preparation for stand-alone (no-embroider) vite and v2-addons we've extracted that into a setConfig function. In ember apps, the most natural place to invoke this function is still from within ember-cli-build, especially as at the moment embroider/macros is still coupled to the app instance as the key for configs.
I think the more natural way to achieve the desired outcome would be to either change the import location (as mentioned in the alternatives) or changing the thing that is imported
store is the most used import for typescript apps and addons, and changing it would be difficult. Especially because it would mean changing it for our own addon which also imports and extends it (ember-data) and sets it as an app re-export. If it even were possible, it would be far more confusing for end users to navigate.
In addition to this, it would require a lot of code duplications as javascript does not allow changing a class into a subclass, and introduce the potential for excess churn as we do have motivations for changing the import in the future, a change that if/when it occurs will have to be carefully coordinated and rolled out over an extensive period of time for the same reasons listed above.
|
All good from RFC Review (1) 👍 |
Advance RFC #1026 `"EmberData | Deprecate Store extending EmberObject"` to Stage Ready for Release
Propose EmberData | Deprecate Store extends EmberObject
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage), followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP