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

Refine component lifecycle hooks #11127

Merged
merged 1 commit into from May 12, 2015
Merged

Refine component lifecycle hooks #11127

merged 1 commit into from May 12, 2015

Conversation

wycats
Copy link
Member

@wycats wycats commented May 12, 2015

This commit refines the lifecycle hooks to more completely support the
use-cases.

On first render (in order):

  • didInitAttrs runs after attrs is guaranteed to be up to date. This
    is more reliable than trying to ensure that attrs are always
    available on init.
  • didReceiveAttrs runs after didInitAttrs (it also runs on
    subsequent re-renders, which is useful for logic that is the same
    on all renders).
  • willRender runs before the template is rendered. It runs when the
    template is updated for any reason (both initial and re-render, and
    regardless of whether the change was caused by an attrs change or
    re-render).
  • didInsertElement runs after the template has rendered and the
    element is in the DOM.
  • didRender runs after didInsertElement (it also runs on subsequent
    re-renders).

On re-render (in order):

  • didUpdateAttrs runs when the attributes of a component have changed
    (but not when the component is re-rendered, via component.rerender,
    component.set, or changes in models or services used by the
    template).
  • didReceiveAttrs, same as above.
  • willUpdate runs when the component is re-rendering for any reason,
    including component.rerender(), component.set() or changes in
    models or services used by the template.
  • willRender, same as above
  • didUpdate runs after the template has re-rendered and the DOM is
    now up to date.
  • didRender, same as above.

Note that a component is re-rendered whenever:

  1. any of its attributes change
  2. component.set() is called
  3. component.rerender() is called
  4. a property on a model or service used by the template has changed
    (including through computed properties).

Because of the Glimmer engine, these re-renders are fast, and avoid
unnecessary work.

This commit refines the lifecycle hooks to more completely support the
use-cases.

On first render (in order):

* `didInitAttrs` runs after `attrs` is guaranteed to be up to date. This
  is more reliable than trying to ensure that `attrs` are always
  available on `init`.
* `didReceiveAttrs` runs after `didInitAttrs` (it also runs on
  subsequent re-renders, which is useful for logic that is the same
  on all renders).
* `willRender` runs before the template is rendered. It runs when the
  template is updated for any reason (both initial and re-render, and
  regardless of whether the change was caused by an attrs change or
  re-render).
* `didInsertElement` runs after the template has rendered and the
  element is in the DOM.
* `didRender` runs after `didInsertElement` (it also runs on subsequent
  re-renders).

On re-render (in order):

* `didUpdateAttrs` runs when the attributes of a component have changed
  (but not when the component is re-rendered, via `component.rerender`,
  `component.set`, or changes in models or services used by the
  template).
* `didReceiveAttrs`, same as above.
* `willUpdate` runs when the component is re-rendering for any reason,
  including `component.rerender()`, `component.set()` or changes in
  models or services used by the template.
* `willRender`, same as above
* `didUpdate` runs after the template has re-rendered and the DOM is
  now up to date.
* `didRender`, same as above.

Note that a component is re-rendered whenever:

1. any of its attributes change
2. `component.set()` is called
3. `component.rerender()` is called
4. a property on a model or service used by the template has changed
   (including through computed properties).

Because of the Glimmer engine, these re-renders are fast, and avoid
unnecessary work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants