You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See this jsbin: http://jsbin.com/mipibunusu/1/edit?html,js,console,output
This jsbin mimics the behaviour of reduce computed and ember data.
In the console output you can see the counter increasing, but then only decreases once.
I did a little digging on this one. Brain dump follows:
Inside ComputedPropertyPrototype.didChange we call removeDependentKeys which calls unwatchhere. After that, the data key is marked as not being watched causing the guard in propertyDidChangehere to do an early return.
This seems like expected (but bizarre) behavior, but I'll let others that are more familiar with the metal caching strategies chime in to confirm.
See this jsbin:
http://jsbin.com/mipibunusu/1/edit?html,js,console,output
This jsbin mimics the behaviour of reduce computed and ember data.
In the console output you can see the counter increasing, but then only decreases once.
I encountered this issue while working on #9492 .
reduce computed counts the number of willChange and didChange. see this line
However, sometimes it did not receive the didChange event, which then causes it not to flush the changes. Especially when ember data is used.
The text was updated successfully, but these errors were encountered: