-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Cached computed properties seem to be invalidated too often #10433
Comments
CP's are lazy, once invalidated something needs to pull the data out of them. imagine the following DK chain foo -> bar -> baz if For many scenarios this actually works fine, and wont cause re-renders. Because of simple template bindings, we "diff" the previous and new value to decide if a re-render is needed. the basic Where this does fall short currently is when dealing with complex objects as values. And we are aware of this. @tomdale and @wycats are currently working on the template rendering side of this problem: tildeio/htmlbars#282. Although the goal is for server side rendering to be scooped up by the client side, it has the potential to help mitigate the issue. On the CP side, we currently have paired changeEvent contract of
Ultimately, the As such I do believe the template rendering side has sufficient context to handle the complex object case much better. Although both solutions could work together, the reactive template approach is likely be the near term solution. |
In our scenario the problem was that Or, is it a bad pattern to have CP which are costly to compute? |
this appears to be work as expected, our view layer should now be more resilient to such changes and prevent unexpected view churn. |
Consider this code:
http://jsfiddle.net/L95npwyj/
The idea is that we have a dependency tree :
And the operations we perform change
lastName
, andfullName
, but notfirstLetter
.The output on the console is:
Ember spec seems to promise to me that
largeFirstLetter
will be recomputed only if it's dependencies are no longer valid. But the experiment reveals that what it actually means is that "deeper" dependencies, such aslastName
are also taken into account. So even thoughfirstLetter
(the only direct dependency oflargeFirstLetter
) does not change, thelargeFirstLetter
gets recomputed.The example above is very simple, but we hit this problem in a more advanced scenario where it was causing a lot of redraws in situations where nothing actually changed.
I've "fixed" it with making
firstLetter
a real (not computed) property, and manually recomputing it using observe('fullName').Am I doing something wrong?
The text was updated successfully, but these errors were encountered: