render(elemento, vnodes)
Descripción
Renderiza una plantilla en el DOM.
m.render(document.body, 'hello');
// <body>hello</body>Firma
m.render(element, vnodes, redraw)
| Parámetro | Tipo | Obligatorio | Descripción |
|---|---|---|---|
element | Element | Sí | Un elemento DOM que actuará como nodo padre del subárbol. |
vnodes | Array<Vnode>|Vnode | Sí | Los vnodes que se van a renderizar. |
redraw | () -> any | No | Una función de callback que se invoca cada vez que se activa un controlador de eventos en el subárbol. |
| devuelve | Retorna undefined. |
Cómo funciona
El método m.render(element, vnodes) recibe un árbol DOM virtual (normalmente generado a través de la función hyperscript m()), genera un árbol DOM y lo inserta en element. Si element ya tiene un árbol DOM insertado a través de una llamada anterior a m.render(), los vnodes se comparan con el árbol de vnodes anterior y el árbol DOM existente se modifica solo donde sea necesario para reflejar los cambios. Los nodos DOM que no han cambiado permanecen intactos.
Si se pasa el argumento opcional redraw, se invoca cada vez que se activa un controlador de eventos en cualquier parte del subárbol. Esto es utilizado por m.mount y m.redraw para implementar la funcionalidad de autoredraw. También se expone para casos de uso más avanzados, como la integración con frameworks de terceros.
m.render es síncrono.
¿Por qué el DOM Virtual?
Puede parecer ineficiente generar un árbol de vnodes en cada redibujado, pero la creación y comparación de estructuras de datos de JavaScript es sorprendentemente económica en comparación con la manipulación directa del DOM.
Manipular el DOM puede ser extremadamente costoso por varias razones. La alternancia de lecturas y escrituras puede afectar negativamente al rendimiento al provocar múltiples repintados del navegador en rápida sucesión, mientras que la comparación de árboles DOM virtuales permite agrupar las escrituras en un solo repintado. Además, el comportamiento del rendimiento de varias operaciones DOM varía entre las implementaciones y puede ser difícil de aprender y optimizar para todos los navegadores. Por ejemplo, en algunas implementaciones, leer childNodes.length tiene una complejidad de O(n); en algunas, leer parentNode provoca un repintado, etc.
En contraste, recorrer una estructura de datos de JavaScript tiene un comportamiento de rendimiento mucho más predecible y consistente. Además, un árbol de vnodes se implementa de tal manera que permite a los motores de JavaScript modernos aplicar optimizaciones agresivas, como clases ocultas, para un rendimiento aún mejor.
Diferencias con otros métodos de la API
El método m.render() se llama internamente por m.mount(), m.route(), m.redraw() y m.request(). No se invoca después de las actualizaciones de flujo.
A diferencia de m.mount() y m.route(), un árbol de vnodes renderizado mediante m.render() no se redibuja automáticamente en respuesta a los eventos de la vista, las llamadas a m.redraw() o las llamadas a m.request(). Es un mecanismo de bajo nivel, pensado para desarrolladores de bibliotecas que desean controlar manualmente la renderización en lugar de depender del sistema de redibujo automático incorporado de Mithril.js.
Otra diferencia es que el método m.render espera un vnode (o un array de vnodes) como su segundo parámetro, mientras que m.mount() y m.route() esperan componentes.
Uso independiente
var render = require("mithril/render")
El módulo m.render tiene un propósito similar al de bibliotecas de vista como Knockout, React y Vue. Implementa un motor de comparación de DOM virtual con un algoritmo moderno de reducción del espacio de búsqueda y reciclaje de DOM, que ofrece un rendimiento excepcional, tanto en términos de carga inicial de la página como de redibujado. No depende de otras partes de Mithril.js aparte de la normalización expuesta a través de require("mithril/render/vnode") y se puede utilizar como una biblioteca independiente.
A pesar de ser relativamente pequeño, el módulo de renderizado es completamente funcional e independiente. Soporta todo lo que se puede esperar: SVG, elementos personalizados y todos los atributos y eventos válidos, sin casos límite extraños ni excepciones que distingan entre mayúsculas y minúsculas. Por supuesto, también soporta completamente componentes y métodos de ciclo de vida.
Al usar m.render como módulo independiente, puede ser útil importar también la función hyperscript para crear los vnodes que se van a renderizar.