Dark Mode

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[PERF beta] @each should remain a stable node for chains.#11990

Merged
rwjblue merged 1 commit intobetafrom
fix-each-beta
Aug 6, 2015
Merged

[PERF beta] @each should remain a stable node for chains.#11990
rwjblue merged 1 commit intobetafrom
fix-each-beta

Conversation

Copy link
Contributor

krisselden commented Aug 5, 2015

@each was designed for chaining, the special cased eager behavior + it invalidating for array changes meant that the EachProxy and chains were rebuilt every array change, instead of the leaves just changing.

`@each` was designed for chaining, the special cased eager behavior + it invalidating for array changes meant that the EachProxy and chains were rebuilt every array change, instead of the leaves just changing.
Conflicts:
packages/ember-runtime/lib/system/each_proxy.js
packages/ember-runtime/tests/mixins/array_test.js
Copy link
Member

stefanpenner Aug 5, 2015

Choose a reason for hiding this comment

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

is this._keys ever legitimately contain prototype extensions? If not, maybe we should make it an EmptyObject. This would allow us to also skip the bellow !keys.hasOwnProperty(key)

Copy link
Member

stefanpenner Aug 5, 2015

Choose a reason for hiding this comment

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

a here it is: https://github.com/emberjs/ember.js/blob/fix-each-beta/packages/ember-runtime/lib/system/each_proxy.js#L79

ya this should be one of those EmptyObjects and we can take the fast-path for x in y without HOP.

Copy link
Contributor Author

krisselden Aug 5, 2015

Choose a reason for hiding this comment

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

It is a empty, this is beta though

Copy link
Member

stefanpenner commented Aug 5, 2015

i believe this needs a deprecation in 1.13.x (and it is worth any tiny pain users may have with an additional deprecation.

Copy link
Member

stefanpenner Aug 5, 2015

Choose a reason for hiding this comment

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

funky whitespace

Copy link
Contributor

raytiley commented Aug 5, 2015

I just want to make sure I'm clear on this cause the wording of the description is a bit confusing.

Say I have

40; });">isOvertime: Ember.computed('shifts.@each.hours', function() {
var total = this.get('shifts').reduce(function (sum, shift) {
return sum + shift.get('hours');
}, 0);
return total > 40;
});

Would employee.set('shifts', [some new array of shifts]); still cause isOvertime to recompute? Or would I need to have both shifts.[] and shifts.@each.hours?

Copy link
Contributor Author

krisselden commented Aug 5, 2015

@raytiley ok, I do need to make it more clear, this is only targeting where people used @each as a leaf. The above property is as is.

Copy link
Contributor

raytiley commented Aug 5, 2015

gotcha... so doing someProp: Ember.computed('items.@each', function() {...}) is not supported which is cool.

Copy link
Member

rwjblue commented Aug 5, 2015

@raytiley - Confirm

Copy link
Member

rwjblue commented Aug 6, 2015

Merging this into beta. I am working on some deprecations specifically for stable that will ensure Ember.observer('foo.@each', function() { }); or Ember.computed('foo.@each', function() { }); are properly deprecated.

rwjblue added a commit that referenced this pull request Aug 6, 2015
[PERF beta] `@each` should remain a stable node for chains.
rwjblue merged commit 2d0127e into beta Aug 6, 2015
rwjblue deleted the fix-each-beta branch August 6, 2015 02:20
Copy link
Contributor

ilkkao commented Aug 6, 2015

This change should be probably mentioned clearly in the next beta release notes. There must be few people like me who have made the switch to 2.0 beta already and won't see the deprecation.

Still a really minor thing, those who use the very latest versions probably follow PRs too.

Copy link
Member

stefanpenner commented Aug 6, 2015

@rwjblue based on ^ should we leave some hints/warnings/asserts/errors in 2.x? Might be a common thing, especially as people who are knew to the concept. We can likely catch the mistake extremely early and instruct the correct usage.

Copy link
Member

rwjblue commented Aug 8, 2015

@stefanpenner / @ilkkao - Helpful assertion added in #12019.

Copy link
Contributor

ilkkao commented Aug 9, 2015

cool, thanks.

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

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants