From e35fc79f0933dfbbe3de18bfbb872fa64f0b2628 Mon Sep 17 00:00:00 2001 From: Leo Horie Date: Wed, 25 May 2016 02:01:27 -0400 Subject: [PATCH] mroe docs --- docs/keys.md | 79 ++++++++++++++++++++++++- docs/render.md | 36 ++++++++++++ docs/trust.md | 152 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 264 insertions(+), 3 deletions(-) create mode 100644 docs/render.md create mode 100644 docs/trust.md diff --git a/docs/keys.md b/docs/keys.md index 37bcfac0..0842febe 100644 --- a/docs/keys.md +++ b/docs/keys.md @@ -2,6 +2,7 @@ - [What are keys](#what-are-keys) - [How to use](#how-to-use) +- [Debugging key related issues](#debugging-key-related-issues) --- @@ -11,7 +12,7 @@ Keys are a mechanism that allows re-ordering DOM elements within a NodeList, and In other words, a `key` is a way of saying "this DOM element is for the data object with this id". -Typically, `key` should be the unique identifier field of the objects in the data array. +Typically, a `key` property should be the unique identifier field of the objects in the data array. ```javascript var users = [ @@ -64,7 +65,7 @@ Worse still, if there were stateful jQuery plugins attached to these buttons, th Even though in this particular example, we humans intuitively guess that the first item in the list was the one being removed, it's actually impossible for a computer to automatically solve this problem for all possible inputs. -Therefore, in the cases when a list of vnodes is derived from a *mutable* array of data, you should add a `key` property to each virtual node that maps to a uniquely identifiable field in the source data. This will allow Mithril to intelligently re-order the DOM to maintain each DOM element correctly mapped to its respective item in the data source. +Therefore, in the cases when a list of vnodes is derived from a dynamic array of data, you should add a `key` property to each virtual node that maps to a uniquely identifiable field in the source data. This will allow Mithril to intelligently re-order the DOM to maintain each DOM element correctly mapped to its respective item in the data source. ```javascript function correctUserList(users) { @@ -74,7 +75,79 @@ function correctUserList(users) { } ``` +--- + +### Debugging key related issues + +Keys can cause confusing issues if they are misunderstood. A typical symptom of key related issues is that application state appears to become corrupted after a few user interactions (usually involving a deletion). + +#### Avoid wrapper elements around keyed elements + +Keys must be placed on the virtual node that is an immediate child of the array. This means that if you wrap the `button` in an `div` in the example above, the key must be moved to the `div`. + +```javascript +// AVOID +users.map(function(u) { + return m("div", [ //key should be in `div` + m("button", {key: u.id}, u.name) + ]) +}) +``` + +#### Avoid hiding keys in component root elements + +If you refactor the code and put the button inside a component, the key must be moved out of the component and placed back where the component took the place of the button. + +```javascript +// AVOID +var Button = { + view: function(vnode) { + return m("button", {key: vnode.attrs.id}, u.name) + } +} +users.map(function(u) { + return m("div", [ + m(Button, {id: u.id}, u.name) //key should be here, not in component + ]) +}) +``` + +#### Avoid wrapping keyed elements in arrays + +Arrays are [vnodes](vnodes.md), and therefore keyable. You should not wrap arrays around keyed elements + +```javascript +// AVOID +users.map(function(u) { + return [ //fragment is a vnode, and therefore keyable + m("button", {key: u.id}, u.name) + ] +}) + +// PREFER +users.map(function(u) { + return m("button", {key: u.id}, u.name) +}) + +// PREFER +users.map(function(u) { + return {tag: "[", key: u.id, children: [ + m("button", u.name) + ]} +}) +``` + +#### Avoid variable types + Keys must be strings if present or they will be cast to strings if they are not. Therefore, `"1"` (string) and `1` (number) are considered the same key. -In addition, keys must be placed on the virtual node that is an immediate child of the array. This means that if you wrap the `button` in an `div` in the example above, the key must be moved to the `div`. Likewise, if you refactor the code and put the button inside a component, the key must be moved out of the component and placed back where the component took place of the button. +You should use either strings or numbers as keys in one array, but not mix both. + +```javascript +// AVOID +var things = [ + {id: "1", name: "Book"}, + {id: 1, name: "Cup"}, +] +``` diff --git a/docs/render.md b/docs/render.md new file mode 100644 index 00000000..488bb0af --- /dev/null +++ b/docs/render.md @@ -0,0 +1,36 @@ +# render(element, vnodes) + +- [Signature](#signature) +- [How it works](#how-it-works) +- [Standalone usage](#standalone-usage) + +--- + +### Signature + +`render(element, vnodes)` + +Argument | Type | Required | Description +----------- | -------------------- | -------- | --- +`element` | `Element` | Yes | A DOM element that will be the parent node to the subtree +`vnodes` | `Array|Vnode` | Yes | The [vnodes](vnodes.md) to be rendered +**returns** | | | Returns nothing + +[How to read signatures](signatures.md) + +--- + +### How it works + +The `m.render(element, vnodes)` method takes a virtual DOM tree (typically generated via the [`m()` hyperscript function](hyperscript.md), generates a DOM tree and appends it to `element`. + +This method is internally called by [`m.mount()`](mount.md) and [`m.route()`](route.md). + +--- + +### Standalone usage + +The `m.render` module is similar in scope to view libraries like Knockout, React and Vue. It is less than 500 lines of code (3kb min+gzip) and implements a virtual DOM diffing engine with a modern search space reduction algorithm and DOM recycling, which translate to top-of-class performance, both in terms of initial page load and re-rendering. It has no dependencies on other parts of Mithril and can be used as a standalone library. + +Despite being incredibly small, the render module is fully functional and self-suficient. It supports everything you might expect: SVG, custom elements, and all valid attributes and events - without any weird case-sensitive edge cases or exceptions. Of course, it also fully supports [components](components.md) and [lifecycle methods](lifecycle-methods.md). + diff --git a/docs/trust.md b/docs/trust.md new file mode 100644 index 00000000..99a4bc3b --- /dev/null +++ b/docs/trust.md @@ -0,0 +1,152 @@ +# trust(html) + +- [Signature](#signature) +- [How it works](#how-it-works) +- [Security considerations](#security-considerations) +- [Scripts that do not run](#scripts-that-do-not-run) +- [Avoid trusting HTML](#avoid-trusting-html) + +--- + +### Signature + +`render(element, vnodes)` + +Argument | Type | Required | Description +----------- | -------------------- | -------- | --- +`html` | `String` | Yes | A string containing HTML text +**returns** | `Vnode` | | A trusted HTML [vnode](vnodes.md) that represents the input string + +[How to read signatures](signatures.md) + +--- + +### How it works + +By default, Mithril escapes all values in order to prevent a class of security problems called [XSS injections](https://en.wikipedia.org/wiki/Cross-site_scripting). + +However, sometimes it is desirable to render rich text and formatting markup. To fill that need, `m.trust` creates trusted HTML [vnodes](vnodes.md) which are rendered as HTML. + +```javascript +var view = m("div", [ + m.trust("

Here's some HTML

") +]) + +m.render(document.body, view) + +// equivalent HTML +//

Here's some HTML

+``` + +Trusted HTML vnodes are objects, not strings; therefore they cannot be concatenated with regular strings. + +--- + +### Security considerations + +You **must sanitize the input** of `m.trust` to ensure there's no user-generated Javascript in the HTML string. If you don't sanitize an HTML string and mark it as a trusted string, any asynchronous javascript call points within the HTML string will be triggered and run with the authorization level of the user viewing the page. + +There are many ways in which an HTML string may contain executable code. The most common ways to inject security attacks are to add an `onload` or `onerror` attributes in `` or `