-
-
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
[Glimmer 2] Difference in willRender
semantics
#13947
Comments
2 tasks
chancancode
added a commit
to glimmerjs/glimmer-vm
that referenced
this issue
Sep 7, 2016
This is to align the semantics with emberjs/ember.js#13947 Currently these things are tested in Ember, but we need to port those tests over soon.
chancancode
added a commit
that referenced
this issue
Sep 7, 2016
This correctly implements the semantics in #13947 Requires the corresponding Glimmer change
This was referenced Sep 7, 2016
Merged
chancancode
added a commit
to glimmerjs/glimmer-vm
that referenced
this issue
Sep 7, 2016
This is to align the semantics with emberjs/ember.js#13947 Currently these things are tested in Ember, but we need to port those tests over soon.
I believe this was resolved by #14222. @chancancode - Can you confirm? |
Note that this also affects |
webark
pushed a commit
to webark/ember.js
that referenced
this issue
Oct 6, 2016
This correctly implements the semantics in emberjs#13947 Requires the corresponding Glimmer change
bantic
added a commit
to bustle/ember-mobiledoc-dom-renderer
that referenced
this issue
Oct 13, 2016
willRender semantics change in glimmer2. willRender is called every time a child component rerenders. We only need to rerender the mobiledoc when the incoming properties (mobiledoc, cardNames, atomNames, etc) change. See: emberjs/ember.js#13947
bantic
added a commit
to bustle/ember-mobiledoc-dom-renderer
that referenced
this issue
Oct 13, 2016
fixes #23 * do rendering work in didReceiveAttrs instead of willRender. willRender semantics change in glimmer2. willRender is called every time a child component rerenders. We only need to rerender the mobiledoc when the incoming properties (mobiledoc, cardNames, atomNames, etc) change. See: emberjs/ember.js#13947 * extract mobiledoc helpers for tests
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Previously,
willRender
only fire when something directly inside the component's template has changed (in other words, dynamic content rendered directly from the component's layout).In Glimmer 2, this hook will fire when anything inside its template subtree has changed, regardless on the depth of the nesting (in other words, dynamic content rendered from the component's layout and also by the child components it invoked from within its layout, their child components, and so on).
Put it simply, the
willRender
hook will be called anytime something is about to be re-rendered anywhere inside the component's element.In the new implementation, the rendering engine does not differenciate between whether some dynamic content is nested "directly" inside a component. (Future optimizations, such as inlining, will make the line even more blurry.) As such, there is no natural place to track that distinction and we cannot rely on the old huristic/semantics.
To our knowledge, the previous behavior is not guaranteed in official documentation. Since
willRender
is mostly used on "leaf" components, we believe the impact will be minimal. Incidentally, this will also enable some use cases that were not previously possible, such as a{{#render-markdown}}...{{/render-markdown}}
component that converts its content from markdown to HTML.If you believe you have usage patterns that are affected by this, please provide as much detail about your scenario as possible below. It is very possible that there can be alternatives and/or targeted solutions we can use that do not require a wholesale change to the engine. Therefore, it would be helpful if you can provide background information and context about your usage instead of just showing us small code snippets from your codebase.
The text was updated successfully, but these errors were encountered: