s/shouldUpdate/onbeforeupdate

docs/components.md

@@ -28,7 +28,7 @@ m(Example)
 
 ### Lifecycle methods
 
-Components can have the same [lifecycle methods](lifecycle-methods.md) as virtual DOM nodes: `oninit`, `oncreate`, `onupdate`, `onbeforeremove`, `onremove` and `shouldUpdate`.
+Components can have the same [lifecycle methods](lifecycle-methods.md) as virtual DOM nodes: `oninit`, `oncreate`, `onupdate`, `onbeforeremove`, `onremove` and `onbeforeupdate`.
 
 ```javascript
 var ComponentWithHooks = {
@@ -48,7 +48,7 @@ var ComponentWithHooks = {
 	onremove: function(vnode) {
 		console.log("removing DOM element")
 	},
-	shouldUpdate: function(vnode, old) {
+	onbeforeupdate: function(vnode, old) {
 		return true
 	},
 	view: function(vnode) {

docs/hyperscript.md

@@ -229,7 +229,7 @@ To learn more about components, [see the components page](components.md).
 
 ### Lifecycle methods
 
-Vnodes and components can have lifecycle methods (also known as *hooks*), which are called at various points during the lifetime of a DOM element. The lifecycle methods supported by Mithril are: `oninit`, `oncreate`, `onupdate`, `onbeforeremove`, `onremove`, and `shouldUpdate`. 
+Vnodes and components can have lifecycle methods (also known as *hooks*), which are called at various points during the lifetime of a DOM element. The lifecycle methods supported by Mithril are: `oninit`, `oncreate`, `onupdate`, `onbeforeremove`, `onremove`, and `onbeforeupdate`. 
 
 Lifecycle methods are defined in the same way as DOM event handlers, but receive the vnode as an argument, instead of an Event object:
 
@@ -248,7 +248,7 @@ Hook                          | Description
 `onupdate(vnode)`             | Runs every time a redraw occurs while the DOM element is attached to the document
 `onbeforeremove(vnode, done)` | Runs before a DOM element is removed from the document, and only triggers the actual removal of the DOM element when the `done` callback is called. This method is only triggered on the element that is detached from its parent DOM element, but not on its child elements.
 `onremove(vnode)`             | Runs before a DOM element is removed from the document. If a `onbeforeremove` hook is defined, `onremove` is called after `done` is called. This method is triggered on the element that is detached from its parent element, and all of its children
-`shouldUpdate(vnode, old)`    | Runs before `onupdate` and if it returns `false`, it prevents a diff for the element and all of its children
+`onbeforeupdate(vnode, old)`    | Runs before `onupdate` and if it returns `false`, it prevents a diff for the element and all of its children
 
 To learn more about lifecycle methods, [see the lifecycle methods page](lifecycle-methods.md).
 

docs/lifecycle-methods.md

@@ -7,7 +7,7 @@
 - [onupdate](#onupdate)
 - [onbeforeremove](#onbeforeremove)
 - [onremove](#onremove)
-- [shouldUpdate](#shouldUpdate)
+- [onbeforeupdate](#onbeforeupdate)
 - [Avoid anti-patterns](#avoid-anti-patterns)
 
 ---
@@ -176,13 +176,13 @@ var Timer = {
 
 ---
 
-### shouldUpdate
+### onbeforeupdate
 
-The `shouldUpdate(vnode, old)` hook is called before a vnode is diffed in a update. If this function is defined and returns false, Mithril prevents a diff from happening to the vnode, and consequently to the vnode's children.
+The `onbeforeupdate(vnode, old)` hook is called before a vnode is diffed in a update. If this function is defined and returns false, Mithril prevents a diff from happening to the vnode, and consequently to the vnode's children.
 
 This hook by itself does not prevent a virtual DOM subtree from being generated unless the subtree is encapsulated within a component.
 
-Like in other hooks, the `this` keyword in the `shouldUpdate` callback points to `vnode.state`.
+Like in other hooks, the `this` keyword in the `onbeforeupdate` callback points to `vnode.state`.
 
 This hook is useful to reduce lag in updates in cases where there is a overly large DOM tree.
 
@@ -194,14 +194,14 @@ Although Mithril is flexible, some code patterns are discouraged:
 
 #### Avoid premature optimizations
 
-The `shouldUpdate` hook should only be used as a last resort. Avoid using it unless you have a noticeable performance issue.
+The `onbeforeupdate` hook should only be used as a last resort. Avoid using it unless you have a noticeable performance issue.
 
-Typically performance problems that can be fixed via `shouldUpdate` boil down to one large array of items. In this context, typically "large" means any array that contains a large number of nodes, be it in a wide spread (the infamous 5000 row table), or in a deep, dense tree.
+Typically performance problems that can be fixed via `onbeforeupdate` boil down to one large array of items. In this context, typically "large" means any array that contains a large number of nodes, be it in a wide spread (the infamous 5000 row table), or in a deep, dense tree.
 
 If you do have a performance issue, first consider whether the UI presents a good user experience and change it if it doesn't. For example, it's highly unlikely that a user would ever sift through 5000 rows of raw table data, and highly likely that it would be easier for a user to use a search feature that returns only the top few most relevant items.
 
-If a design-based solution is not feasible, and you must optimize a UI with a large number of DOM element, apply `shouldUpdate` on the parent node of the largest array and re-evaluate performance. In the vast majority of cases, a single check should be sufficient. In the rare case that it is not, rinse and repeat, but you should be increasingly wary of each new `shouldUpdate` declaration. Multiple `shouldUpdate`s are a code smell that indicates prioritization problems in the design workflow.
+If a design-based solution is not feasible, and you must optimize a UI with a large number of DOM element, apply `onbeforeupdate` on the parent node of the largest array and re-evaluate performance. In the vast majority of cases, a single check should be sufficient. In the rare case that it is not, rinse and repeat, but you should be increasingly wary of each new `onbeforeupdate` declaration. Multiple `onbeforeupdate`s are a code smell that indicates prioritization problems in the design workflow.
 
-Avoid applying the optimization to other areas of your application "just-in-case". Remember that, generally speaking, more code incurs a higher maintenance cost than less code, and `shouldUpdate` related bugs can be especially difficult to troubleshoot if you rely on object identity for its conditional checks.
+Avoid applying the optimization to other areas of your application "just-in-case". Remember that, generally speaking, more code incurs a higher maintenance cost than less code, and `onbeforeupdate` related bugs can be especially difficult to troubleshoot if you rely on object identity for its conditional checks.
 
-Again, **the `shouldUpdate` hook should only be used as a last resort.**
+Again, **the `onbeforeupdate` hook should only be used as a last resort.**