-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[QUEST] 🌲Project Trim 🌲 #6166
Comments
@lifeart hate to tell you this but we've got the codemod and lint rules mostly ready to go already. rfc-data: https://github.com/ember-data/ember-data-rfc395-data I think we still need to update the lint plugin to pull from this rfc-data |
@runspired good news! @dcyriller should we move codemod into https://github.com/ember-codemods ? |
I created an issue to discuss that over in the codemod repo... |
@lifeart good idea, sure I'll do that. Let me fix a bug and initiate the migration. |
There is node a lint rule PR here: ember-cli/eslint-plugin-ember#450 |
From emberjs#6166 This refactors some tests so that they don't rely on the `createStore` test helper. `createStore` was helpful in the past but is less so now that we have [nice APIs for dependency injection](https://guides.emberjs.com/release/applications/dependency-injection/). --- One test was removed from `unit/store/adapter-interop - Store working with a Adapter` because I don't think it was correct. Here was the test: https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/unit/store/adapter-interop-test.js#L28-L32 This test was, at one time, testing that it was possible to pass a factory as the `adapter` property to `Store`. This feature was removed in emberjs#3191 but the test continued passing because of the way the `createStore` works. https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/helpers/store.js#L57-L60
From emberjs#6166 This refactors some tests so that they don't rely on the `createStore` test helper. `createStore` was helpful in the past but is less so now that we have [nice APIs for dependency injection](https://guides.emberjs.com/release/applications/dependency-injection/). --- One test was removed from `unit/store/adapter-interop - Store working with a Adapter` because I don't think it was correct. Here was the test: https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/unit/store/adapter-interop-test.js#L28-L32 This test was, at one time, testing that it was possible to pass a factory as the `adapter` property to `Store`. This feature was removed in emberjs#3191 but the test continued passing because of the way the `createStore` works. https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/helpers/store.js#L57-L60
From emberjs#6166 This refactors some tests so that they don't rely on the `createStore` test helper. `createStore` was helpful in the past but is less so now that we have [nice APIs for dependency injection](https://guides.emberjs.com/release/applications/dependency-injection/). --- One test was removed from `unit/store/adapter-interop - Store working with a Adapter` because I don't think it was correct. Here was the test: https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/unit/store/adapter-interop-test.js#L28-L32 This test was, at one time, testing that it was possible to pass a factory as the `adapter` property to `Store`. This feature was removed in emberjs#3191 but the test continued passing because of the way the `createStore` works. https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/helpers/store.js#L57-L60
From emberjs#6166 This refactors some tests so that they don't rely on the `createStore` test helper. `createStore` was helpful in the past but is less so now that we have [nice APIs for dependency injection](https://guides.emberjs.com/release/applications/dependency-injection/). --- One test was removed from `unit/store/adapter-interop - Store working with a Adapter` because I don't think it was correct. Here was the test: https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/unit/store/adapter-interop-test.js#L28-L32 This test was, at one time, testing that it was possible to pass a factory as the `adapter` property to `Store`. This feature was removed in emberjs#3191 but the test continued passing because of the way the `createStore` works. https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/helpers/store.js#L57-L60
From emberjs#6166 This refactors some tests so that they don't rely on the `createStore` test helper. `createStore` was helpful in the past but is less so now that we have [nice APIs for dependency injection](https://guides.emberjs.com/release/applications/dependency-injection/). --- One test was removed from `unit/store/adapter-interop - Store working with a Adapter` because I don't think it was correct. Here was the test: https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/unit/store/adapter-interop-test.js#L28-L32 This test was, at one time, testing that it was possible to pass a factory as the `adapter` property to `Store`. This feature was removed in emberjs#3191 but the test continued passing because of the way the `createStore` works. https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/helpers/store.js#L57-L60
From #6166 This refactors some tests so that they don't rely on the `createStore` test helper. `createStore` was helpful in the past but is less so now that we have [nice APIs for dependency injection](https://guides.emberjs.com/release/applications/dependency-injection/). --- One test was removed from `unit/store/adapter-interop - Store working with a Adapter` because I don't think it was correct. Here was the test: https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/unit/store/adapter-interop-test.js#L28-L32 This test was, at one time, testing that it was possible to pass a factory as the `adapter` property to `Store`. This feature was removed in #3191 but the test continued passing because of the way the `createStore` works. https://github.com/emberjs/data/blob/39182f324d5777e4a75c4a582f0791631e37d8de/packages/-ember-data/tests/helpers/store.js#L57-L60
Part of emberjs#6166 Follow up to emberjs#6347 This replaces usage of the `setupStore` helper for `tests/integration/relationships/*`.
Part of emberjs#6166 Follow up to emberjs#6347 This replaces usage of the `setupStore` helper for `tests/integration/relationships/*`.
Part of emberjs#6166 Follow up to emberjs#6347 This replaces usage of the `setupStore` helper for `tests/integration/relationships/*`.
Part of emberjs#6166 This replaces usage of the `setupStore` helper for `tests/integration/adapter/*`.
Is this up to date? It looks like there has been little progress since December 2019. |
Is this up to date? |
@ryanolsonx yes it is :) |
#8078 once merged will complete all internalModel tasks, so I've checked them off. This leaves primarily the RecordData v2 tasks (and request coalescing). |
Once #8122 lands we will have only one last lonely task to complete this epic! It's a tricky one, but its also a key bit of code re-shuffling as we prepare to introduce the replacement for adapter/serializer. With Trim complete, the focus will primarily shift to the items in the roadmap for 5.0 #8086. However, there's been a long running epic (without a publicly attached issue) to "unplug" from Ember itself, where to "unplug" means that we are no longer dependent on any framework code and could be used by the broader JS community as desired. The 5.0 Roadmap accomplishes the major steps needed for this, but there are tons of things not on that roadmap we could use help with. If folks are interested I can whip up a tracking ticket. |
Awesome work runspired! We've doubled the sponsorship to "Extra Appreciative Of The Work" now. Looking forward to 5.0! If folks are interested (see runspired's question above), we are willing to sponsor contributions on Ember Data (we're already sponsoring 3 people contributing to Ember Data). |
At long last 👋 |
🌲 Project Trim🌲
As the Ember Community approaches delivery of long awaited features enabling tree-shaking, ember-data needs to take some steps to enable this feature to shed the weight of features that consuming applications do not use.
The first step is to ensure that the packages
ember-data
provides are properly encapsulated. In many cases, this will both enable support for tree-shaking once available to the broader community and enable manually opting for a subset of packages.Later steps will ensure that
ember-data
relies on explicit imports (whether automatically generated at build-time or declared by consuming applications) where currently we rely on resolver lookups.🌲 Use
ember-data
without@ember-data/serializer
The serializer package provides reference serializer implementations and a base serializer class that are not required for applications that choose to write a custom serializer implementing the minimal serializer interface. This includes the
EmbeddedRecordsMixin
and the baseTransform
class.Transforms, while specified via
attr
available from@ember-data/model
are a concept specific to these reference serializers and not used anywhere else withinember-data
. Custom serializers thus may or may not choose to use them via the same mechanism (owner.lookup('transform:<name>')
). Lastly theTransform
base class merely shows the interface required fortransforms
but is not required to be used as a base class.Action Items
[FEAT] - add a public Typescript interface for the minimal required serializer interface #6113[DOC serializer] implements MinimumSerializerInterface #6451 add a public Typescript interface for the minimal required serializer interface-default
and-json-api
serializer (use app re-exports instead)-default
serializer fallback inStore.serializerFor
Adapter.serializer
andAdapter.defaultSerializer
fallbacks (which currently default to-json-api
.Model.toJSON
and support the scenario for quick debug-mode inspection viadebugData()
method which inDEBUG
would print a similar object to the currenttoJSON
method.-rest
serializer fallback usage in tests-json-api
serializer fallback usage in tests-default
serializer fallback usage in tests🌲 Use
ember-data
without@ember-data/adapter
The adapter package provides reference adapter implementations and a base adapter class that are not required for applications that choose to write a custom adapter implementing the minimal adapter interface.
Action Items
-rest
and-json-api
adapter (use re-export pattern for-json-api
adapter)Store.defaultAdapter
(-json-api
) and the-json-api
adapter fallback behavior-rest
adapter which is only available for tests at this point unless consumers manually calladapterFor('-rest')
.findMany
is optionalfindBelongsTo
is optionalfindHasMany
is optionalshouldReloadRecord
is optionalshouldBackgroundReloadRecord
is optionalshouldReloadAll
is optionalshouldBackgroundReloadAll
is optionalisInvalidError
flag or specific message instead ofinstanceof InvalidError
instore
errorsArrayToHash
uses the privatestore
version🌲 Use
ember-data
without@ember-data/model
While at the time of writing this quest
@ember-data/model
is the only model class available for use withember-data
based on public APIs, the introduction of custom Model Classes will mean that users who install@ember-data/model
alternatives via addon or by writing their own should be able to consumeember-data
without using a package which provides a model implementation they do not use.Enabling use without
@ember-data/model
requires much more groundwork than that needed for theadapter
andserializer
package.Model Action Items
Model
from thestore
package into theModel
package.@hasMany
and@belongsTo
into theModel
package.-private/system/relationships/ext.js
in@ember-data/store
into theModel
packageManyArray
andPromiseManyArray
into theModel
package. See RFC notesPromiseBelongsTo
into theModel
package.Model
specific_modelForMixin
implementation into the store from theModel
package (this provides the multi-inheritance polymorphism feature which some aspects ofember-data
currently support).BelongsToReference.push
receiving aModel
instanceIdentifiers
RFC.Record
toRecordIdentifier
to occur within@belongsTo
and@hasMany
BLOCKED requires RecordData V2InternalModel Action Items
Reference.internalModel
propertyStore.getReference
to not lookup the associatedInternalModel
to generate the reference.Model
package.InternalModel
RecordData Errors RFC
Request State RFC
.InternalModel
into theModel
package. (this is the LegacySupport class)InternalModel Cleanup Action Items
Once the items in
InternalModel Action Items
are complete, we can move the instantiation and lookup logic in theStore
into theModel
package.InternalModel
only for@ember-data/model
when using theinstantiateRecord
hook.Store._internalModelForId
usage in favor ofIdentifier
based logic.🌲 Use
ember-data
without@ember-data/relationship-layer
The
relationship-layer
package is currently deeply entangled with@ember-data/model
'sModel
implementation. Even though we can encapsulate the imports to/from these packages, users would not be able to use@ember-data/model
without also using@ember-data/relationship-layer
. Additionally, in its current form therelationship-layer
is not abstracted away from the specifics of the implementation ofModel
making is largely unusable with otherModel
implementations. Changes to address this are needed but are outside the scope of this quest, and until such time as they occur users wishing to drop this package would need to drop both this and theModel
package together.-private/system/relationships/state
in@ember-data/store
into a newrelationship-layer
package. See RFC notesbelongsToReference
andHasManyReference
intorelationship-layer
from store.internalModel
to pull information from theRecordIdentifier
or theStore
fortype
id
hasRecord
andgetRecord()
into a private middleware to be used by the private -request-manager service(moved into the model layer to make it easier to write alternative relationship fetching logic for a new relationship layer)🌲 Use
ember-data
without@ember-data/debug
Provides the DataAdapter for the ember-inspector
detect
should not requireModel
🌲 Use
ember-data
without@ember-data/record-data
Provides the default RecordData implementation
RecordData
into this package(stretch goal)Land RecordDataV2 Note: blocker on a key bit of model refactoring, no longer stretch goal(stretch goal)Public Docs for RecordDatastore
package to implementcreateRecordDataFor
(stretch goal) Move RecordData interface tests into the encapsulation test appMisc
createStore
andsetupStore
createStore
test helper #6347 remove all createStore usagecreateStore
-default
serializer ifmoduleFor
style tests are still supported-default
serializer when this condition is detected🌲 Tree Shaking Strategy
embroider
is pursuing a strategy in which consuming applications opt in to enabling tree-shaking of specific kinds of features once they have determined for their own application that this is allowable. For certain kinds of things embroider provides an escape hatch to not-shake. Currently this includes models, adapters, and serializers and their usage is not easy to statically analyze. Here we outline our plan for reducing the costs of these primitives, but these are not a requirement to complete ProjectTrim.Models - Users will be able to opt-in to a new lighter-weight model experience
This model experience would be heavily informed by ember-m3 (which configures ember-data via public APIs to use its own model). Goals would be for model files to be optional, and to make their usage tree-shakeable.
Adapters/Serializers - Once the deprecation of automatic adapter fallbacks is resolved, we could find a way to let embroider know that the adapters in @ember-data/adapter are shakeable if no user adapter imports them. However, we primarily recommend dropping the adapter package entirely in favor of authoring an adapter specific to your application's need. Further design work here is needed but going forward the plan is to introduce a network-layer that allows registration ofuser-supplied network middlewares. Such middlewares, including those provided by addons, would be imported and registered with the
request-manager
service directly. Since these are static imports being registered to a service, in the long term no custom infrastructure would be needed to support tree-shaking. A legacy middleware would delegate request management to existing adapters/serializers, removal of which would allow for full tree-shaking.Also in the long-term, serializers would be deprecated in favor of either their corresponding "adapter" replacement handling these concerns or in favor of middlewares specific to normalization and serialization concerns. Similarly, in the long term no custom infra for ensuring static imports for tree-shaking needs would be required.
Transforms - There are three ways for a user to utilize a
transform
today:attr(<transformName>)
,owner.lookup('transform:<transformName>')
and direct import of a transform followed byTransform.create()
. Of these, the third already plays nicely with tree-shaking. Forattr
andlookup
usage we will need to enforce "static string usage" forlookup
and andattr()
, at which point we can use this to generate an import file of only those transforms that are actually in-use. Alternatively, we may decide to deprecate transforms altogether in favor of transformations which do not require a container lookup.Also note, if none of the default serializers is in use and there is no project usage of
lookup('transform:<transformName>')
then it is likely we can drop all transforms even when referenced byattr
.Note that using the adapter/serializer/record-data/model/debug packages is entirely optional already. If you are not using code from these packages and/or would prefer your own implementation of the public-interface they implement then installing @ember-data/store and whatever other @ember-data/ packages you require directly instead of installing
ember-data
will result in both the code those packages bring not being present and any code the store contains for configuring them to be removed at build-time.🌲 Tree Shake all of
ember-data
deprecateno longer required due to injections having been deprecated and removed, but is a nice-to-have.defaultStore
behavior inEmber
controller/route
The text was updated successfully, but these errors were encountered: