Ember Component Life-cycle Docs Feedback

component.js

import Ember from 'ember';

export default Ember.Component.extend({
  /**
   Overall thoughts: Ember.Component needs a section in the module doc block outlining the order of events (just like the 1.13 blog post).
   Individual events can then refer back to that lifecycle chart to avoid the "runs xth during re-renders but only on thursdays" sentences.
   The module doc block should also get the section on what triggers a re-render (from the 1.13 blog post).
  */

  myProp: null,

  /**
  @didInitAttrs()

  Runs after a component was created and passed attrs are guaranteed to be present. In Ember 1.13, the attributes will be available as this.get('attrName').
  (Are attrs not guaranteed to be present during `init()`?)
  In my limited experience, it's easy to make the mistake of implementing methods that only fire during the first render, assuming your attrs will never change. I wonder if that should be gently discouraged.
  In this case, steering people towards `didReceiveAttrs` or `willRender` might be the wisest course.

  - Runs first on initial render
  - Setting internal component properties in this hook is ok (does not trigger warning/deprecation)

  */
  didInitAttrs() {
    console.log('didInitAttrs');
  },

  /**
  @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).
  What does this sentence mean? I think your sentence below ("Runs only when a bound attribute is changed from the outside") makes much more sense than this.

  - Runs 1st on re-renders, when an external attr has changed
  - Does not run when an internal property is set()
  - Setting properties in this hook is ok (does not trigger warning/deprecation)

  */
  didUpdateAttrs() {
    console.log('didUpdateAttrs');
  },

  /**
  @didReceiveAttrs()

  As mentioned above, might be good to position this as the place to put code unless you specifically need to target initial- or re- renders.

  - Runs after didInitAttrs, on initial render
  - Runs after didUpdateAttrs, on re-renders, when an external attr has changed
  - Does not run when an internal property is set()
  - Setting properties in this hook is ok (does not trigger warning/deprecation)

  */
  didReceiveAttrs() {
    console.log('didReceiveAttrs');
  },

  /**
  @didInsertElement()

  Runs after the template has rendered and the element is in the DOM.
  Just like with `didInitAttrs`, this feels like a less-safe place to put code that needs to interact with the DOM than in `didRender`, because you don't always know which internal DOM elements will be replaced by a re-render (so it's not always save to use this to grab & cache references to DOM nodes).
  Might be good to steer folks towards `didRender` instead (especicially since this has been the place to do your custom DOM work in the past)

  - Runs after `willRender`, on initial render only
  - Setting properties in this hook which would result in a template re-render is NOT ok (triggers warning/deprecation)

  */
  didInsertElement() {
    console.log('didInsertElement');
  },

  /**
  @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.

  - Runs after `didReceiveAttrs` on re-renders when an external attr has changed
  - Runs first on re-renders when the component updates its own properties (via `this.set()`)
  - Setting properties in this hook is ok (does not trigger warning/deprecation)

  */
  willUpdate() {
    console.log('willUpdate');
  },

  /**
  @didUpdate()

  Runs after the template has re-rendered and the DOM is now up to date.

  - Runs after `willRender` during re-renders (not run during initial render)
  - Setting properties in this hook which would result in a template re-render is NOT ok (triggers warning/deprecation)

  */
  didUpdate() {
    console.log('didUpdate');
  },

  /**
  @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).

  - Runs after `didReceiveAttrs` on initial render
  - Runs after `willUpdate` on re-renders
  - Setting properties in this hook is ok (does not trigger warning/deprecation)

  */
  willRender() {
    console.log('willRender');
  },

  /**
  @didRender()

  Runs after didInsertElement (it also runs on subsequent re-renders).
  It seems like this is a much better place to put code that interacts with the DOM than `didInsertElement`

  - Always runs last
  - Setting properties in this hook which would result in a template re-render is NOT ok (triggers warning/deprecation)

  */
  didRender() {
    console.log('didRender');
    console.log('----------------------');
  },

});