render(element, vnodes)
Description
Affiche un template dans le DOM.
m.render(document.body, 'hello');
// <body>hello</body>Signature
m.render(element, vnodes, redraw)
| Argument | Type | Required | Description |
|---|---|---|---|
element | Element | Yes | Un élément DOM qui sera le nœud parent de l'arbre. |
vnodes | Array<Vnode>|Vnode | Yes | Les vnodes à afficher. |
redraw | () -> any | No | Une fonction de rappel (callback) invoquée chaque fois qu'un gestionnaire d'événements dans le sous-arbre est appelé. |
| returns | Renvoie undefined. |
Fonctionnement
La méthode m.render(element, vnodes) prend un arbre de DOM virtuel (généralement généré via la fonction m() hyperscript), génère un arbre DOM et l'attache à l'element. Si l'element a déjà un arbre DOM attaché via un appel m.render() précédent, les vnodes sont comparés à l'arbre des vnodes précédents et l'arbre DOM existant est modifié uniquement là où cela est nécessaire pour refléter les changements. Les nœuds DOM inchangés ne sont pas modifiés.
Si vous passez l'argument optionnel redraw, il est invoqué chaque fois qu'un gestionnaire d'événements est appelé n'importe où dans le sous-arbre. Ceci est utilisé par m.mount et m.redraw pour implémenter la fonctionnalité de redessin automatique, mais il est également exposé pour des cas d'utilisation plus avancés, comme l'intégration avec certains frameworks tiers.
m.render est synchrone.
Pourquoi le DOM virtuel
Il peut sembler inefficace de générer un arbre de vnodes à chaque redessin, mais il s'avère que la création et la comparaison de structures de données JavaScript sont étonnamment peu coûteuses par rapport à la lecture et à la manipulation du DOM.
Manipuler le DOM peut être extrêmement coûteux pour plusieurs raisons. L'alternance des lectures et des écritures peut nuire aux performances en provoquant plusieurs recalculs de rendu du navigateur en succession rapide, alors que la comparaison des arbres DOM virtuels permet de regrouper les écritures en une seule re-peinture. De plus, les caractéristiques de performances des différentes opérations DOM varient d'une implémentation à l'autre et peuvent être difficiles à apprendre et à optimiser pour tous les navigateurs. Par exemple, dans certaines implémentations, la lecture de childNodes.length a une complexité de O(n) ; dans certaines, la lecture de parentNode provoque une repeinture, etc.
En revanche, le parcours d'une structure de données JavaScript a un profil de performances beaucoup plus prévisible et stable. De plus, un arbre de vnodes est implémenté de manière à permettre aux moteurs JavaScript modernes d'appliquer des optimisations agressives telles que les hidden classes pour des performances encore meilleures.
Différences par rapport aux autres méthodes API
La méthode m.render() est appelée en interne par m.mount(), m.route(), m.redraw() et m.request(). Elle n'est pas appelée après les mises à jour de streams.
Contrairement à m.mount() et m.route(), un arbre de vnodes rendu via m.render() ne se redessine pas automatiquement en réponse aux événements de la vue, aux appels m.redraw() ou aux appels m.request(). Il s'agit d'un mécanisme de bas niveau adapté aux développeurs de bibliothèques qui souhaitent contrôler manuellement le rendu au lieu de s'appuyer sur le système de redessin automatique intégré de Mithril.js.
Une autre différence est que la méthode m.render attend un vnode (ou un tableau de vnodes) comme deuxième paramètre, tandis que m.mount() et m.route() attendent des composants.
Utilisation autonome
var render = require("mithril/render")
Le module m.render a une portée similaire à celle des bibliothèques de rendu comme Knockout, React et Vue. Il implémente un moteur de différenciation DOM virtuel avec un algorithme moderne de réduction de l'espace de recherche et de recyclage du DOM, ce qui se traduit par des performances de premier ordre, tant en termes de chargement initial de la page que de re-rendu. Il n'a aucune dépendance vis-à-vis d'autres parties de Mithril.js, à l'exception de la normalisation fournie via require("mithril/render/vnode") et peut être utilisé comme une bibliothèque autonome.
Bien qu'il soit relativement petit, le module de rendu est entièrement fonctionnel et indépendant. Il prend en charge tout ce que vous pouvez attendre : SVG, éléments personnalisés, et tous les attributs et événements valides - sans aucun traitement spécifique sensible à la casse. Bien sûr, il prend également entièrement en charge les composants et les méthodes de cycle de vie.
Lorsque vous utilisez m.render comme un module autonome, il peut être utile d'importer également la fonction hyperscript pour créer les vnodes à afficher.