search

emberjs / ember.js

Ember.js - A JavaScript framework for creating ambitious web applications
https://emberjs.com
MIT License
22.46k stars 4.21k forks source link

[Glimmer 2] Removal of "always dirty" re-rendering #13946

Closed chancancode closed 7 years ago

chancancode commented 8 years ago

Previously, calling this.rerender() on a component would force everything in its template subtree to recompute, including helpers like {{unbound}} and other custom helper. This is done by walking all the "render nodes" with a "always-dirty visitor".

In Glimmer 2, the entire system is built to avoid doing unnecessary work. There is no equivalent concept to "render nodes". In many of cases, the system can tell that nothing in a sub-tree has changed without traversing it at all. Sometimes the system can even tell that certain things (like {{unbound}} and constant values in the templates) are not going to change and optimize out the work ahead-of-time.

Therefore, there isn't necessarily an equivalent strategy we can use without defeating these optimizations.

To our knowledge, the previous behavior is not guaranteed in official documentation. It is usually used to work around issues that are fixed in the new system. For example, {{#each-in}} now tracks all the changes to the object automatically (as long as they are added through Ember.set), and does not require manual re-render.

If you believe you have usage patterns that are affected by this, please provide as much details about your scenario as possible below. It is very possible there are alternatives and/or targeted solutions we can use that do not require a wholesale change to the engine's optimization strategies. Therefore, it would be helpful for you to provide more background information and context about your usage instead of just showing us small code snippets from your codebase.

fivetanley commented 7 years ago

@chancancode We are having a pretty hard time trying to fix the deprecations for this in our app. A lot of these deprecations point at ember/glimmer internals and make it difficult to decipher where exactly the deprecation is being triggered from. You modified (no label) in the screenshot below is one example. The debugging curve here has been pretty hard and making this an assertion would prevent us from upgrading without someone who knows the internals of Ember metal/glimmer fairly well.

screen shot 2016-11-07 at 9 51 46 am

While we agree that this is the correct behavior going forward, we would like to help at least try to make the messaging better if you have time to provide some guidance.

fivetanley commented 7 years ago

These messages also happen during the rerender queue, meaning they get scheduled far away from when the property was actually changed. This often removes the ability to follow the stack to figure out which thing changed, causing the rerender.

fivetanley commented 7 years ago

My bad, my comments belonged on https://github.com/emberjs/ember.js/issues/13948 instead.

kiwiupover commented 7 years ago

@fivetanley congrats on landing a job at heroku!