ractivejs/ractive — pull request #1236 by martypdx (2014-09-21 17:28:51+00:00)
Title: Lifecycle events

Not ready for merge, looking for feedback before wrapping this up.

### What I like so far (but open to suggestions):

* I decided to go with the `on` prefix for methods because
* the current `render` method would have needed to be repurposed, and
* it allows the current API to be depreciated rather than being broken.
* I followed the DOM convention of all lowercase methods (`oninit`, `onrender`). I think it fits well with rest of API and ractive's touch of retro browser style.
* Both methods and events (without the "on": `this.on('render')`) supported (we can easily add an option to only do one or the other if people want to cut down on noise).

The current hooks are:
##### `onconstruct`
Same as current `beforeInit`, has the constructor `options` as argument
##### `onconfig`
All options have been "compiled" for the instance based on inheritance and any function options, but viewmodel or view has not been created yet.
##### `oninit` *
The viewmodel and the virtualDOM (root fragment) have been created, but no rendering has occurred. Only fires once per instance.
##### `onrender` *
The view has been rendered. Can be called more than once if instance is unrendered.
##### `onchange`
Existing `change` event
##### `oncomplete` *
Existing `complete` event.
##### `onunrender` *
New event, companion to `onrender`. Can be called more than once.
##### `onteardown`
Like existing `teardown`, except slight change in that it has been moved to after unrender when teardown causes unrender (which is most of the time).

### Where I'm still unsure

#### hierarchy hook names

The hooks marked with `*` above are really two hooks. One that happens when the instance itself is ready (bottom-up), and one that happens when the hierarchy is ready (top-down). The current `init` method is top-down. (Note: I need to research `complete`, I'm not sure it applies but I think it does)

A case could be made that we only need the top-down hooks. If that were the case, I would use the current names as-is. But much of the time (or maybe most of the time), it may be fine to address the instance immediately when it's ready (this is how it worked up until a couple of releases ago). And I suspect that there may be cases when you _need_ to do something in a child _before_ the parent does something, in which case we would want to have both hooks. The issue would then be that it may make more sense for the bottom-up event to have the name listed above.

There are two options:

##### present and past tense
`oninit` and `oninited`
`onrender` and `onrendered`
`onunrender` and `onunrendered`

PROS:
* It makes the most sense linguistically that the bottom-up is immediate, and the top-down is past-tense.
CONS:
* If top-down are most common, it makes them a bit longer.
* Bit unfortunate that `oninited` seems awkward in English.

##### prefix the bottom-up
Currently going with `pre`. `before` doesn't really make sense. Another options would be `this`
`onpreinit` and `oninit`
`onprerender` and `onrender`
`onpreunrender` and `onunrender`
PROS:
* If top-down is most common, makes it the most natural
* We can defer adding in bottom-up hooks.
CONS:
* Some linguistic awkwardness

#### render vs insert

I need to look at rendered a bit more closely, as it needs to make sense it terms of DOM nodes being create versus actual in the DOM. This may shed more light on naming questions above.