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

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

Merged
merged 1 commit into from
Aug 6, 2015

Conversation

krisselden
Copy link
Contributor

@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

if (lim>0) { removeObserverForContentKey(content, key, this, idx, lim); }

let keys = this._keys;
Copy link
Member

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

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

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

@stefanpenner
Copy link
Member

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

@@ -22,7 +22,7 @@ var SPLIT_REGEX = /\{|\}/;
Ember.expandProperties('{foo,bar}', echo); //=> 'foo', 'bar'
Ember.expandProperties('foo.{bar,baz}', echo); //=> 'foo.bar', 'foo.baz'
Ember.expandProperties('{foo,bar}.baz', echo); //=> 'foo.baz', 'bar.baz'
Ember.expandProperties('foo.{bar,baz}.@each', echo) //=> 'foo.bar.@each', 'foo.baz.@each'
Ember.expandProperties('foo.{bar,baz}.[]', echo) //=> 'foo.bar.[]', 'foo.baz.[]'
Copy link
Member

Choose a reason for hiding this comment

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

funky whitespace

@raytiley
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

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?

@krisselden
Copy link
Contributor Author

@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.

@raytiley
Copy link
Contributor

raytiley commented Aug 5, 2015

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

@rwjblue
Copy link
Member

rwjblue commented Aug 5, 2015

@raytiley - Confirm

@rwjblue
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 rwjblue merged commit 2d0127e into beta Aug 6, 2015
@rwjblue rwjblue deleted the fix-each-beta branch August 6, 2015 02:20
@ilkkao
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.

@stefanpenner
Copy link
Member

@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.

@rwjblue
Copy link
Member

rwjblue commented Aug 8, 2015

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

@ilkkao
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants