Ember.computed.sort has serious flaw in 2.x+

[workmanw]

After spending the entire morning I've finally figure this out. It's kind of hard to explain, but let's start with a demo: http://emberjs.jsbin.com/pagoguyofa/edit?html,js,output . Notice that the {{my-list}} component uses Ember.computed.sort and there is two instances of the component in the DOM. Clicking the button to move an item only causes one of the {{my-list}} component instances to update.

To understand why, you have to look at the implementation of Ember.computed.sort. First, and most important, the computed macro creates a new computed property for each declaration, not for each component instance. See: reduce_computed_macros.js#L566. This means that every component instance of the same type will ultimately share the same computed property.

Next, every time the value is computed, it clears out all prior observers and rebuilds them. See: reduce_computed_macros.js#L568. There inlies the problem because since the computed property lives on the class, it clears all other observers for other instances of the same component.

Does that make sense to anyone?

[workmanw]

One possible solution would be to filter out foreign observers before calling removeObserver and then not resetting the op._sortPropObservers list each time. Example:

if (cp._sortPropObservers) {
  let thisObservers = cp._sortPropObservers.filterBy('firstObject', this);
  thisObservers.forEach(args => removeObserver.apply(null, args));
  cp._sortPropObservers.removeObjects(thisObservers);
} else {
  cp._sortPropObservers = [];
}

That said, the current implementation feels a tad bit dangerous memory wise that a class ends up with [potentially dangling] references to instances. Looking for some advice on the best way to fix this. It's blocking us from moving to 2.x at the moment.

[stefanpenner]

Ah crap ya, this is bad (and my fault). I believe storing the observers on the CP was an omission, it really is a more complex relationship

@workmanw if you can provide a failing test i can likely work on it this afternoon or tomorrow morning.

[workmanw]

@stefanpenner Yea, that shouldn't be a problem. I'll do it now.

[stefanpenner]

@stefanpenner Yea, that shouldn't be a problem. I'll do it now.

thanks

[workmanw]

@stefanpenner Added: #12215

To demonstrate the validity of this test, if you comment out cp._sortPropObservers.push(args); in Ember.computed.sorts definition, you'll see the test passes.

Thanks a lot!

[workmanw]

@stefanpenner Any progress on this? I know you've got the WeakMap RFC and PR ... unfortunately we cannot move to 2.x until this issue is resolved.

[stefanpenner]

Been on vacation. Will take a look this Sunday (feel free to pester me on Sunday :p)

[workmanw]

Hehe. Thank you. I know you have a million things on your plate. I'm happy to help if there is any work you want to delegate. But it seems the WeakMap may require low level Ember/Javascript knowledge that I don't possess.

[stefanpenner]

That pr just needs feature flagging for the public API. If you have cycles to spare, that would push it over the edge