Renders a template to the DOM
m.render(document.body, "hello") // <body>hello</body>
||Yes||A DOM element that will be the parent node to the subtree|
||Yes||The vnodes to be rendered|
How to read signatures
How it works
m.render(element, vnodes) method takes a virtual DOM tree (typically generated via the
m() hyperscript function, generates a DOM tree and mounts it on
element already has a DOM tree mounted via a previous
vnodes is diffed against the previous
vnodes tree and the existing DOM tree is modified only where needed to reflect the changes. Unchanged DOM nodes are not touched at all.
m.render is synchronous.
Why Virtual DOM
Touching the DOM can be extremely expensive for a couple of reasons. Alternating reads and writes can adversely affect performance by causing several browser repaints to occur in quick succession, whereas comparing virtual dom trees allows writes to be batched into a single repaint. Also, the performance characteristics of various DOM operations vary between implementations and can be difficult to learn and optimize for all browsers. For example, in some implementations, reading
childNodes.length has a complexity of O(n); in some, reading
parentNode causes a repaint, etc.
Differences from other API methods
m.render() method is internally called by
m.request(). It is not called after stream updates
m.route(), a vnode tree rendered via
m.render() does not auto-redraw in response to view events,
m.redraw() calls or
m.request() calls. It is a low level mechanism suitable for library authors who wish to manually control rendering instead of relying on Mithril's built-in auto-redrawing system.
Another difference is that
m.render method expects a vnode (or a array of vnodes) as its second parameter, whereas
m.route() expect components.
var render = require("mithril/render")
m.render module is similar in scope to view libraries like Knockout, React and Vue. It is approximately 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-sufficient. 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 and lifecycle methods.
License: MIT. © Leo Horie.