[4.12->5.x]: Model.inverseFor(...).type was class, is now a string

[robbytx]

Reproduction

ember-cli/ember-new-output@v4.12.3...robbytx:ember-new-output:inverseFor

• ember-cli/ember-new-output@05c081c - test passes (Model.inverseFor(...).type is a Model class) with [email protected]
• ember-cli/ember-new-output@d7ad3df - test still passes with [email protected]
• ember-cli/ember-new-output@9cc5951 - test fails on [email protected]

Description

Per https://api.emberjs.com/ember-data/4.11/classes/Model/methods/inverseFor?anchor=inverseFor:

store.modelFor('post').inverseFor('comments', store) // { type: App.Message, name: 'owner', kind: 'belongsTo' }

This is/was the documented behavior for all of the released 4.x series, as demonstrated by the above tests.

In #8020 (comment), this documentation was claimed to be incorrect, and at some point in the 5.x series, the behavior of Model.inverseFor was in fact changed such that the type property became a string value instead.

This change is reflected at https://api.emberjs.com/ember-data/5.3/classes/Model/methods/inverseFor?anchor=inverseFor:

store.modelFor('post').inverseFor('comments', store) // { type: 'message', name: 'owner', kind: 'belongsTo' }

However, no deprecation was included in the 4.x series, and I cannot find any notice of this API compatibility change.

Versions

• 4.x through 4.12 - Model.inverseFor(...).type is a class
• 5.4 - Model.inverseFor(...).type is a string
• 4.13.0-alpha.8 - Model.inverseFor(...).type is a string

[robbytx]

Following is the test failure when running against ember-data 5.4.1:

[runspired]

I'm going to close this as part of #9639 where I'll also make a note of it.

Some back context: in 5.x we shipped types (which is part of the changeset ported back to 4.13). In order to do so we typed Model which surfaced that type was sometimes a string and sometimes a class on the schema produced for Model depending on which codepaths were accessed and how the relationship was configured. In the interest of both sanity and because accessing the raw class without using modelFor is dangerous, this was fixed to only return strings.

At some point in the early days of SproutCore when AppResolver was how sproutcore worked (which later became ember's app resolver), passing the class in this location was how the modeling layer worked. That carried on until sometime in the ~mid 2.x to early 3.x era when investment into rationalizing the internals, fixing the performance of relationships, and cleaning up internal-model resulted in the api being converted to using a string. The docs were never updated and some portion of the code that was unused by the library itself continued to return a class. This went by unnoticed until typescript alerted us to the mixed return type.

In general, starting in 4.x the schema service should always be used to lookup information about a record, and direct use of the static classes should be avoided. In 4.12+ this is as simple as store.schema.fields({ type }).