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

Deprecate defaultStore located at Route.store #377

Closed
runspired opened this issue Sep 18, 2018 · 4 comments
Closed

Deprecate defaultStore located at Route.store #377

runspired opened this issue Sep 18, 2018 · 4 comments
Labels
T-deprecation T-ember-data RFCs that impact the ember-data library T-framework RFCs that impact the ember.js library

Comments

@runspired
Copy link
Contributor

runspired commented Sep 18, 2018

See (private) docs for this intimate API that often trolls users of ember-engines and ember-data.

https://emberjs.com/api/ember/3.4/classes/Route/methods/store?anchor=store&show=inherited%2Cprivate

Motivations

  • address learning concerns around where ember ends and ember-data begins, specifically:
    • clarify that Route.model() is not named model "because it returns ember-data models"
    • clarify that Route.model() is not 1:1 with an ember-data model and remove confusion about whether routes are allowed to have more than one model
    • remove confusion around folks thinking that routes (and dynamic params in routes) must be 1:1 with API endpoints
    • squash bugs where routes have multiple dynamic params attempt to rely on store.find
    • squash bugs where dynamic params cannot have the same name
    • demystify how the model() hook works and demystify how to request data with ember-data
    • allow ember-data to drop the long vestigial store.find method
    • remove confusion around why store is available but not the right store in engines when folks forget to wire up store
    • remove a common reason developers believe ember-data is required
    • remove a common reason developers believe ember-data is ember
  • enable ember-data to kill the eager initializer and eager instance-initializer necessary to override defaultStore (prevents tree shaking, is a perf hit when apps don't need ember-data to render the entry route, and limits ember-data's ability to evolve the Store's APIs)
  • move to a pattern of explicit store injection, instead of magical injection on routes and controllers
  • enable folks to write unit and integration tests that register the store without needing to first unregister the store due to the eager initializer ( this is a silent and very annoying bug to encounter )
  • prepare for a world in which partitioning data can be a first class route concern
  • prepare for a world in which request management is first class instead of spooky action at a distance
  • prepare for a world in which ember-data may be adopted incrementally
  • trim the default size of ember, which includes significant infrastructure to support defaultStore

For folks that want this magical behavior, an optional addon that reopens route with either a "DefaultStore" mixin or an "ember-data route store" mixin would be more in keeping with being leaner and more explicit.

@runspired
Copy link
Contributor Author

@rwjblue had done some exploration on deprecating this, unsure where it stalled but this prevents ember-data from cleaning up various initializer patterns which hinder the ability for folks to write tests that register a store without first unregistering the store service.

@locks locks added T-ember-data RFCs that impact the ember-data library T-framework RFCs that impact the ember.js library and removed T-ember-data RFCs that impact the ember-data library labels Sep 18, 2018
@rwjblue
Copy link
Member

rwjblue commented Sep 27, 2018

Just saw the default store mentioned in a video linked in the most recent Ember Weekly: https://youtu.be/EcKaDu0xo_A

@runspired
Copy link
Contributor Author

this was covered by #955

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-deprecation T-ember-data RFCs that impact the ember-data library T-framework RFCs that impact the ember.js library
Projects
Archived in project
Development

No branches or pull requests

4 participants