Ember Data JavaScript Modules API #238
Conversation
| | Global | Module | | ||
| |--- | --- | | ||
| | `DS.Serializer` | `import Serializer from '@ember-data/serializer'` | | ||
| | `DS.EmbeddedRecordsMixin` | `import EmbeddedRecordsMixin from '@ember-data/serializer/src/embedded-record-mixin'` | |
There was a problem hiding this comment.
This should be @ember-data/serializer/src/embedded-records-mixin (note records as plural)
|
|
||
| # Detailed design | ||
|
|
||
| Ember Data will stick with 1 top level namespace of `@ember-data`. Under it there are 6 nested module |
There was a problem hiding this comment.
why @ember-data instead of @ember/data as proposed in https://emberjs.com/blog/2017/04/05/emberconf-2017-state-of-the-union.html#toc_ember-in-2017?
|
|
||
| Ember Data will stick with 1 top level namespace of `@ember-data`. Under it there are 6 nested module | ||
| namespaces where exposed components could live. Someday these namespaces could be moved into their own | ||
| top level scoped package (for example `@ember-data/serializer` could become `@ember-data/serializer`) however, |
There was a problem hiding this comment.
what's the difference between @ember-data/serializer and @ember-data/serializer?
There was a problem hiding this comment.
Bad edit from the draft.
| # Alternatives | ||
|
|
||
| The easiest alternative would be to continue using the current exports. | ||
| Alternatively, we could use the current shims, which do not follow the RFC #176 heuristics as closely. |
There was a problem hiding this comment.
import attr from 'ember-data/attr; and company.
If you generate a model in Ember Twiddle you'll unfortunately see what I mean :P
| | Global | Module | | ||
| |--- | --- | | ||
| | `DS.Store` | `import Store from '@ember-data/store'` | | ||
| | `DS.AdapterPopulatedRecordArray` | `import AdapterPopulatedRecordArray from '@ember-data/store/src/adapter-populated-record-array'` | |
There was a problem hiding this comment.
src in the module import path is needed due to the new module unification semantics, which obviously makes it a little harder to build nice looking APIs based on import paths. IMHO we should first figure out how we could accomplish nice looking paths and then afterwards think about new Ember Data module APIs. Otherwise we might create more churn than needed.
|
What's the reasoning behind using the What probably makes sense, is that most people don't need all the adapters and serializers that are included by default (I don't need the RESTAdapter if I only use the JSONAPIAdapter) and they could be left out. But in my opinion this should be solved by a different solution than splitting up the whole library into small chunks. For example tree shaking could make them have no costs for end users and they could stay in the main package or maybe they could be separated into their own addons. But I guess this would be a concern of a different RFC. So I think it makes more sense, to keep Ember Data as a single package instead of using a scope with multiple packages, to avoid unnecessary complexity. |
|
One thing we discussed in the core team meeting today was keeping Ember data under the
This would also allow us to break out modules we no longer wish to ship with the default distribution into packages like:
|
|
The link in the top comment is incorrect. Should be https://github.com/emberjs/rfcs/blob/ember-data-modules/text/0000-ember-data-javascript-module-api.md . |
|
Thanks, updated. |
|
@t-sauer while this RFC doesn't explicitly mention it (maybe it should), a meta package could be used to include all of the 6 ember-data dependencies (hopefully keeping the name |
|
@Samsinite we already have the meta package named |
|
@locks exactly what I assumed, was just addressing t-sauer's concern. Thanks for clarifying! |
|
I am no longer the right person to push this forward, and it would necessitate a complete rewrite at any rate. |
Rendered
Originally authored by @bmac.