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

Get firstObject/lastObject notification only when cached #5591

Conversation

opichals
Copy link
Contributor

Created Em.Array#arrayFirstLastObjectChange abstraction in order to be able to override the Em.Array#firstObject/lastObject notification implementation which by default calls #objectAt(0) and #objectAt(length-1).

These calls are not optimal in case of e.g. sparse RecordArrays which would trigger unnecessary content[index] requests.

Consider an example of using Ember.ListView which only pulls the rendered items out of the content array. In case the content is an ArrayController which dynamically loads items as rendered the Em.Array would actually request the index of 0 and length-1 even in cases where those index content items are not to be rendered at all and therefore trigger unnecessary store layer roundtrips.

@bradleypriest
Copy link
Member

Is this related to #5379?

@opichals opichals force-pushed the first_last_object_changes_overridable branch from a9a3510 to 0994684 Compare September 18, 2014 13:27
@opichals
Copy link
Contributor Author

Yes, it is basically the same thing.

I have updated the PR with a test and a variation of the #5379 mentioned diff https://gist.github.com/mmun/877bad33158578a8609b. The cache checks should IMO however do only presence check, not using the cache value (compare with undefined).

@wagenet
Copy link
Member

wagenet commented Nov 1, 2014

@mmun ping

@opichals opichals force-pushed the first_last_object_changes_overridable branch from d42d433 to 70d6f47 Compare November 14, 2014 10:19
@petrvolny
Copy link
Contributor

Hey, is there anything that blocks this from merging?

@rwjblue
Copy link
Member

rwjblue commented Aug 2, 2015

Looks like this needs another rebase. I'll to mention this in the upcoming meeting to see if folks are generally 👍 or 👎...

@opichals opichals force-pushed the first_last_object_changes_overridable branch from 70d6f47 to 53b58ce Compare August 5, 2015 20:18
@opichals
Copy link
Contributor Author

rebased...

@krisselden
Copy link
Contributor

@opichals the cache check is not correct, we should also provide in meta an isCached method, so this mistake isn't copied anymore. The idea should be if we don't think it is safe to recheck, we just fire the change event. It should not be that people can override the firing of the event, it should just be to override rechecking it against objectAt(), we could even limit the recheck to just the NativeArray mixin

@krisselden
Copy link
Contributor

@rwjblue I've reviewed it now, what I mentioned needs to be addressed before merging.

@opichals opichals force-pushed the first_last_object_changes_overridable branch 2 times, most recently from f837d94 to 5c712ba Compare August 11, 2015 08:58
@opichals
Copy link
Contributor Author

Did a quick cache['x'] !== undefined necessary change. The other comments could be addressed in another PR.

@opichals opichals force-pushed the first_last_object_changes_overridable branch from 5c712ba to 72d0c3e Compare August 11, 2015 09:16
@homu
Copy link
Contributor

homu commented Feb 10, 2016

☔ The latest upstream changes (presumably #12942) made this pull request unmergeable. Please resolve the merge conflicts.

@opichals opichals force-pushed the first_last_object_changes_overridable branch 3 times, most recently from 9ed61a7 to 1dc8e16 Compare February 17, 2016 13:40
@opichals
Copy link
Contributor Author

@krisselden

The idea should be if we don't think it is safe to recheck, we just fire the change event. It should not be that people can override the firing of the event, it should just be to override rechecking it against
objectAt()

Firing the fake change would cause the user of SparseArray to call the get('firstObject') and get('lastObject') which would not prevent the on-deman load of the items as described in the last paragraph of the description of this PR.

rebased

@krisselden
Copy link
Contributor

@opichals I agree it should have the same lazy behavior as a CP and not notify if nothing has actually computed firstObject. I agree with the test.

What I'm against is making this hook public API so that it is ok to prevent a change event even when something has consumed firstObject or lastObject. Checking for undefined is actually a presence check, undefined is cached using a special internal value since in checks are expensive.

If the test and fix were separate from trying to introduce a new public API, I would be happy to merge this. /cc @mmun @rwjblue

@krisselden krisselden self-assigned this Feb 19, 2016
@opichals opichals force-pushed the first_last_object_changes_overridable branch 2 times, most recently from 601c10b to fe2c05c Compare April 1, 2016 07:31
@opichals
Copy link
Contributor Author

opichals commented Apr 1, 2016

@krisselden Thanks, agreed. Updated and rebased.

var meta = peekMeta(this);
var cache = meta && meta.readableCache();
if (cache) {
if (cache['firstObject'] !== undefined &&
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use 2 space indentation, the 4 spaces here (and below) are causing the build failures).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ping @opichals (I think that this is the main blocker).

@opichals opichals force-pushed the first_last_object_changes_overridable branch from fe2c05c to 818081d Compare April 11, 2016 18:52
@opichals opichals changed the title Allow overriding the firstObject/lastObject notification implementation No get firstObject/lastObject notification when not cached Apr 11, 2016
@opichals opichals force-pushed the first_last_object_changes_overridable branch from 818081d to e5959e2 Compare April 11, 2016 19:07
@opichals opichals force-pushed the first_last_object_changes_overridable branch from e5959e2 to 7bbbd6a Compare April 11, 2016 19:08
@opichals opichals changed the title No get firstObject/lastObject notification when not cached Get firstObject/lastObject notification only when cached Apr 11, 2016
@acorncom
Copy link
Contributor

@opichals Tests seem to be failing here, could you fix those?

@krisselden
Copy link
Contributor

It looks like a circular reference issue with the module imports.

@homu
Copy link
Contributor

homu commented Jun 15, 2016

☔ The latest upstream changes (presumably #13658) made this pull request unmergeable. Please resolve the merge conflicts.

@stefanpenner
Copy link
Member

i'll take this

@stefanpenner
Copy link
Member

rebase and tracking this over here -> #14493

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

Successfully merging this pull request may close these issues.

9 participants