Skip to content

Deprecate defaultStore located at Route.store #377

@runspired

Description

@runspired

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-deprecationT-ember-dataRFCs that impact the ember-data libraryT-frameworkRFCs that impact the ember.js library

    Type

    No type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions