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

Issue using afterInfinityModel #123

Closed
chbonser opened this issue Dec 15, 2015 · 5 comments
Closed

Issue using afterInfinityModel #123

chbonser opened this issue Dec 15, 2015 · 5 comments

Comments

@chbonser
Copy link

When using the afterInfinityModel feature if you don't return the resolved promise then _doUpdate throws "TypeError: infinityModel.pushObjects is not a function".

The example and documentation do not make this requirement clear. My suggestion is that either:

  1. _afterInfinityModel should return infinityModelPromiseResult in all cases (including when afterInfinityModel is a function)
  2. Update the documentation to make it clear that afterInfinityModel must return the resolved object

I can help with a PR for one of the two options if desired.

@hhff
Copy link
Collaborator

hhff commented Dec 15, 2015

i'd like to get @davidgoli thoughts here

@davidgoli
Copy link
Collaborator

I agree the docs are a bit confusing, but the way it works now is whatever you return from afterInfinityModel takes the place of the resolved promise object, UNLESS you return a falsy value (null or undefined or false), in which case infinityModelPromiseResult is returned. So basically, if you don't return anything from your afterInfinityModel, you're good, it should just work. If you return something, it should be an ArrayProxy of some kind. Perhaps just clarifying that in the docs is all we need.

I would not support option 1 here, because I think an important use case for afterInfinityModel is returning a different collection from what Ember Data returns, for instance converting the immutable DS.RecordArray into a mutable ArrayProxy, or mapping or filtering the returned data somehow. Overriding the promise result is pretty useful in lots of ways.

@davidgoli
Copy link
Collaborator

Alternatively we could test the returned value from afterInfinityModel and throw an sensible error if it's not usable.

@chbonser
Copy link
Author

@davidgoli I missed that returning a falsy value causes infinityModelPromiseResult to be returned. That woudl work fine for my use case. I understand your reasons for not liking option 1. I'll try to put together a PR to update the docs tomorrow.

@hhff
Copy link
Collaborator

hhff commented Jan 19, 2016

@chbonser you're the man thankyou

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants