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.

Sign up for GitHub

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

Jump to bottom

EmberData | SchemaService #1027

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

EmberData | SchemaService #1027

wants to merge 10 commits into from
+1,170 −0

Conversation

runspired
Copy link
Contributor

@runspired runspired commented May 11, 2024 •
edited by achambers

Propose EmberData | SchemaService

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.

@runspired runspired added T-ember-data RFCs that impact the ember-data library T-deprecation labels May 11, 2024
@runspired runspired self-assigned this May 11, 2024
@github-actions github-actions bot added the S-Proposed In the Proposed Stage label May 11, 2024
This was referenced May 11, 2024
Open
Closed
MrChocolatine
MrChocolatine reviewed May 11, 2024
View reviewed changes
text/1027-ember-data-schema-service.md Outdated Show resolved Hide resolved
text/1027-ember-data-schema-service.md Outdated Show resolved Hide resolved
text/1027-ember-data-schema-service.md Outdated Show resolved Hide resolved
text/1027-ember-data-schema-service.md Outdated Show resolved Hide resolved
text/1027-ember-data-schema-service.md Outdated Show resolved Hide resolved
text/1027-ember-data-schema-service.md Outdated Show resolved Hide resolved
@runspired @MrChocolatine
Apply suggestions from code review
4b18487 
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
@runspired runspired added S-Exploring In the Exploring RFC Stage and removed S-Proposed In the Proposed Stage labels May 17, 2024
@runspired
Copy link
Contributor Author

Open Questions we covered today:

  • should schema APIs still support objects for looking up resource type info, or should we shift to string type only?
    • consensus: unify on objects
  • homework: what should hasTrait be named? Is hasTrait even needed?
    • homework: do we also need isTrait(string)?
  • homework: what is the best design for enabling schema-array to utilize a key for object stability?

@runspired runspired mentioned this pull request May 17, 2024
Merged
5 tasks
acorncom
acorncom reviewed May 19, 2024
View reviewed changes
text/1027-ember-data-schema-service.md
Date.

Transformations ensure that the value in the cache is always in a raw serialized form even when
your App wants to conceptualize the state as something richer.
Copy link
Contributor

Choose a reason for hiding this comment

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

My impression based on earlier RFCs (or discussions with you @runspired, can't remember which) was that transformations were something we were steering away from because of their fraught nature.

Looking at this though, it looks like what we're saying is the previous style of transformations was "transform results prior to storing in cache" and we're instead moving to a "transform fields on retrieval from cache for use in JS / UI". Is that an accurate statement?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is yes. Moving transforms to the new locations does a few things:

  • they become a record concern instead of a serializer concern, in the process providing an actual guarantee of running where before they more-often-than-not would go unused
  • they now prevent the cache from being polluted with non-serializable state
  • they handle the create/update case where before create/update would lead to invalid cache state (strings instead of numbers etc)
  • it fixes defaultValue handling
  • it removes reliance on the resolver
  • it allows them to function as runtime types/validations

runspired added a commit to emberjs/data that referenced this pull request May 22, 2024
@runspired
feat: implement SchemaService RFC emberjs/rfcs#1027
f52c007
runspired added a commit to emberjs/data that referenced this pull request May 22, 2024
@runspired
feat: impl SchemaService RFC (#9448)
b54f476 
* feat: implement SchemaService RFC emberjs/rfcs#1027

* add deprecations, fix prod test

* delegating schema provider

* cleanup'
@runspired runspired mentioned this pull request May 22, 2024
Merged
@runspired
Copy link
Contributor Author

After internal discussion, the Data team has decided we're ready to advance this to FCP!

@richgt richgt mentioned this pull request May 24, 2024
Merged
@achambers
Copy link
Contributor

Looks good to RFC Review (1).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@acorncom acorncom acorncom left review comments

@richgt richgt richgt left review comments

@MrChocolatine MrChocolatine MrChocolatine left review comments

Assignees

@runspired runspired

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
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
5 participants
@runspired @achambers @acorncom @richgt @MrChocolatine