4.13 Canary | Regression Tracking

[runspired]

WONTFIX

• transforms now come from a public instead of private import location
• setConfig may be required?
• extending @ember-data/store instead of ember-data/store now requires full configuration
• super in hooks in classes extending @ember-data/store no longer works
• model._notifyProperties has been removed
• cache is stricter:
  • You must include an 'id' for the resource data ${resource.type}
  • Missing Resource Type: received resource data with a type '${resource.type}' but no schema could be found with that name.

MAYBEFIX

• adapter.useFetch is assigned in a new way, resulting in the getter approach in app adapters not working. fields approach works e.g. useFetch = false.
• isRelationship and isAttribute on field meta is no longer present. These were meant to be private and not part of the spec, but some apps may have discovered and made use of them.
• relationship graph uses the passed in arrays from operations that update remote state for perf, this exposes them to accidental mutation later. We should consider freezing and/or slicing these arrays in debug as this is mostly an issue with tests using mirage.
  • This can result in Relationship state sometimes storing non-stable identifiers
• hasMany relationships will notify any time they receive an updated payload even if the state is exactly the same due to the fix in # for ensuring we notify for potential re-ordering. (feb6e5a#diff-6bf06ca7b029990de472c9fae36ea1e7e074b8e3d8ddfaf87edc2b5eb41e5d76R154)
• existing notification bug where we will notify attribute keys that aren't in the schema (e.g. due to the API returning keys that aren't in the schema which is really common in Mirage) can lead to over-notification issues now that we subscribe to these notifications in the Request component.

TO FIX

• deprecated registerSchema does not setup schema in a way that avoids the store attempting to call createSchemaService
• getSchemaDefinitionService only checks for schemas registered with registerSchema
• receiving a new request with the same id as the original request in the request component can error because the second request will be backgrounded and we don't account for that in the request validation. Error is The `request` passed to `RequestManager.request(<request>)` was empty (`{}`). Requests need at least one valid key.
• ember-inflector support initializer needs to be backported

[nickschot]

Trying out 4.13-alpha.4 (upgraded from latest 4.12) I ran into what appears to be an inflection issue.

Did anything change in that area, or am I missing something else?

Model definition with @belongsTo('media', { inverse: null, async: true }) media; with a model named media.js now throws Error: No model was found for 'medium' and no schema handles the type at runtime.

It's set up with the inflector as: Inflector.inflector.uncountable('media', 'media');

[runspired]

@nickschot great find! in 5.x we deprecated support for ember-inflector. 5.x deprecations are activateable in 4.13 but off-by-design since they would be new deprecations.

To manage that deprecation, we automatically intercept inflections from ember-inflector and add them to our own inflection library.

That interception logic in ember-data may not be setup right in 4.13, or you may be assembling the packages yourself (as opposed to using ember-data) in which case the interception needs to be explicitly installed in your app. I'll look into the former.

Sidenote: the check if (macroCondition(dependencySatisfies('ember-inflector', '*'))) { will fail if ember-inflector is not installed by your app as a direct dependency iirc.

[nickschot]

Some quick answers to that & a bit more context:

• ember-inflector was already a direct devdep of the app
• we use ember-data and extend the store from ember-data/store, but I did have to install @ember-data/store and @warp-drive/build-config for it to build/boot. There is a bit of customisation of the store service, but it does call super etc.
• @embroider/macros is also a direct dep
• I tried to check if the macroConditions in request-utils/deprecation-support even run, but I don't see them triggered. I noticed in current ember-data that's imported here: https://github.com/emberjs/data/blob/main/packages/-ember-data/app/initializers/ember-data.js#L1 while something like that doesn't appear to be present in 4.13 https://github.com/emberjs/data/blob/v4-main/packages/-ember-data/app/initializers/ember-data.js (I don't know the depth of the other imports there, but it might be a hint).
• the app doesn't use Embroider, latest auto-import is present.

EDIT:

• After manually importing deprecation-support in an initializer it seems to work, so looks like it might just be that import missing somewhere.

[runspired]

Thanks! I'll get that initializer backported :)