Ember Data JavaScript Modules API

[locks]

Rendered

Originally authored by @bmac.

[josemarluedke]

This should be @ember-data/serializer/src/embedded-records-mixin (note records as plural)

[Turbo87]

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?

[Turbo87]

what's the difference between @ember-data/serializer and @ember-data/serializer?

[locks]

Bad edit from the draft.

[Turbo87]

what current shims?

[locks]

import attr from 'ember-data/attr; and company.
If you generate a model in Ember Twiddle you'll unfortunately see what I mean :P

[Turbo87]

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.

[t-sauer]

What's the reasoning behind using the @ember-data scope?
As far as I understood the reason behind the @ember scope was to work towards standalone modules (e.g. @ember/array) which can be removed from applications if they are not needed.
Does the same idea apply to Ember Data? I would assume that if Ember Data is used in a project, it is probably used entirely (e.g. not only models and transforms). So probably most (if not all) applications have 6 packages just to get Ember Data working, which seems to be unnecessary complicated for new people ("Why do I need to add six packages just to use this one library?").

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.

[tomdale]

One thing we discussed in the core team meeting today was keeping Ember data under the @ember scope, to communicate that it's an "official," core-supported package. Then we would have things like:

• @ember/data/store
• @ember/data/model

This would also allow us to break out modules we no longer wish to ship with the default distribution into packages like:

• @ember/json-api-adapter

[lolmaus]

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 .

[rwjblue]

Thanks, updated.

[Samsinite]

@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 ember-data) to make it so only one module is explicitly depended on in the package.json file.

[locks]

@Samsinite we already have the meta package named ember-data, and like RFC #176, it isn't strictly about how the packages are published, as we are scheduled to land the new modules api in 2.16 through the ember-source addon.

[Samsinite]

@locks exactly what I assumed, was just addressing t-sauer's concern. Thanks for clarifying!

[locks]

I am no longer the right person to push this forward, and it would necessitate a complete rewrite at any rate.