Skip to content
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

Closed
chancancode opened this issue Jul 29, 2016 · 3 comments
Closed

[Glimmer 2] Difference in willRender semantics #13947

chancancode opened this issue Jul 29, 2016 · 3 comments

Comments

@chancancode
Copy link
Member

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.

@chancancode chancancode added this to the Glimmer2-Beta milestone Jul 29, 2016
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
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.
@rwjblue
Copy link
Member

rwjblue commented Sep 7, 2016

I believe this was resolved by #14222.

@chancancode - Can you confirm?

@chancancode
Copy link
Member Author

@rwjblue #14222 correctly implemented what is described here, but this issue is describing the difference between htmlbars and glimmer 2 (before #14222, it was "somewhere in between")

@rwjblue rwjblue modified the milestones: Glimmer2-Beta, 2.9.0 Sep 15, 2016
@runspired
Copy link
Contributor

Note that this also affects didRender semantics.

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
@rwjblue rwjblue closed this as completed Apr 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants