Fix keys, normalize holes (#2452)

* Fix #2434

* Treat holes as unkeyed, normalize boolean/null/undefined

This brings a lot better consistency with that API, even though it's
slightly breaking. (I had to update a bunch of tests to correspond with
it.)

* Fill in PR number [skip ci]

docs/keys.md

@@ -75,6 +75,27 @@ function correctUserList(users) {
 }
 ```
 
+Also, you might want to reinitialize a component. You can use the common pattern of a single-item keyed fragment where you change the key to destroy and reinitialize the element.
+
+```javascript
+function ResettableToggle() {
+	var toggleKey = false
+
+	function reset() {
+		toggleKey = !toggleKey
+	}
+
+	return {
+		view: function() {
+			return [
+				m("button", {onclick: reset}, "Reset toggle"),
+				[m(Toggle, {key: toggleKey})]
+			]
+		}
+	}
+}
+```
+
 ---
 
 ### Debugging key related issues
@@ -178,6 +199,10 @@ m("div", [
 ])
 ```
 
+In fact, this will cause an error to be thrown, to remind you to not do it. So don't do it!
+
+Note that `null`s, `undefined`s, and booleans are considered unkeyed nodes. If you want the keyed equivalent, use `m.fragment({key: ...}, [])`, a keyed empty fragment.
+
 #### Avoid passing model data directly to components if the model uses `key` as a data property
 
 The `key` property may appear in your data model in a way that conflicts with Mithril's key logic. For example, a component may represent an entity whose `key` property is expected to change over time. This can lead to components receiving the wrong data, re-initialize, or change positions unexpectedly. If your data model uses the `key` property, make sure to wrap the data such that Mithril doesn't misinterpret it as a rendering instruction: