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

EmberData | deprecate Store extends EmberObject #1026

Merged
merged 4 commits into from
Jun 14, 2024

Conversation

runspired
Copy link
Contributor

@runspired runspired commented May 11, 2024

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 Exploring label 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

  • The team believes the concepts described in the RFC should be pursued.
  • The label S-Proposed is removed from the PR and the label S-Exploring is added.
  • The Ember team is willing to work on the proposal to get it to Accepted

Checklist to move to Accepted

  • This PR has had the Final Comment Period label has been added to start the FCP
  • The RFC is announced in #news-and-announcements in the Ember Discord.
  • The RFC has complete prose, is well-specified and ready for implementation.
    • All sections of the RFC are filled out.
    • Any unanswered questions are outlined and expected to be answered before Ready for Release.
    • "How we teach this?" is sufficiently filled out.
  • The RFC has a champion within one of the relevant teams.
  • The RFC has consensus after the FCP period.

@github-actions github-actions bot added the S-Proposed In the Proposed Stage label May 11, 2024
@runspired runspired self-assigned this May 11, 2024
@runspired runspired added T-ember-data RFCs that impact the ember-data library T-deprecation labels May 11, 2024
runspired and others added 2 commits May 11, 2024 03:08
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
@runspired
Copy link
Contributor Author

discussed in EmberData meeting, moving to FCP

@ef4
Copy link
Contributor

ef4 commented May 17, 2024

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.

Comment on lines +56 to +62
const app = new EmberApp(defaults, {
emberData: {
deprecations: {
DEPRECATE_STORE_EXTENDS_EMBER_OBJECT: false
}
}
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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? 😂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@achambers
Copy link
Contributor

All good from RFC Review (1) 👍

@ef4 ef4 merged commit 5ff97c0 into master Jun 14, 2024
8 checks passed
ef4 added a commit that referenced this pull request Oct 4, 2024
Advance RFC #1026 `"EmberData | Deprecate Store extending EmberObject"` to Stage Ready for Release
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Final Comment Period S-Exploring In the Exploring RFC Stage T-deprecation T-ember-data RFCs that impact the ember-data library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants