Skip to content
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

[DATA] Deprecate exports of managed classes #400

Closed
runspired opened this issue Nov 16, 2018 · 2 comments
Closed

[DATA] Deprecate exports of managed classes #400

runspired opened this issue Nov 16, 2018 · 2 comments
Labels
T-deprecation T-ember-data RFCs that impact the ember-data library

Comments

@runspired
Copy link
Contributor

The following classes only function properly when they are instantiated as classes managed by the store. We should deprecate public import access to them for this reason. Where necessary, APIs should be created to enable creation of managed instances for tests as appropriate (see #396 for an example of one that needs this).

  • DS.PromiseManyArray

  • DS.ManyArray

  • DS.Snapshot

  • DS.PromiseArray

  • DS.PromiseObject

  • DS.RecordArray

  • DS.AdapterPopulatedRecordArray

  • DS.RecordarrayManager

  • DS.Relationship

  • (some folks have used) DS.Errors

  • (private but intimate) DS.InternalModel

  • (private but intimate) DS.RootState

@runspired runspired added T-ember-data RFCs that impact the ember-data library T-deprecation labels Nov 16, 2018
@mydea
Copy link
Contributor

mydea commented Nov 19, 2018

Not sure, but we do use PromiseObject and PromiseArray in our apps.
As an example usage, there are places where we build "fake relationships" with computed promises, like this:

export default Model.extend({
  ajax: service(),
  name: attr(),
  fakeRelationship: computed('id', function() {
     let promise = this.ajax.request(`/my-special-endpoint/${this.id}`);
     return PromiseArray.create({ promise });
  })
});

This way, we can use this in our app the same way as all other relationships, and do not need to know which relationships are "real" and which aren't - which is nice, and allows us to easily switch them with "real" relationships if the API changes or similar.

@runspired
Copy link
Contributor Author

Covered by #743

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-deprecation T-ember-data RFCs that impact the ember-data library
Projects
None yet
Development

No branches or pull requests

2 participants