![\"Arbre](\"/static/d96fec10d250eace9756f09543bf5d58/00d43/implementation-notes-tree.png\" "\\"\\"")
\n \n \n \n Cette section fournit un ensemble de notes relatives à l’implémentation du réconciliateur “stack”.
\nC’est très technique et suppose une solide compréhension de l’API publique de React ainsi que de sa structure divisée en noyau, moteurs de rendu et réconciliateur. Si vous ne connaissez pas bien la base de code React, lisez d’abord l’aperçu du code source.
\nÇa suppose également de comprendre les différences entre les composants React, leurs instances et leurs éléments.
\nLe réconciliateur “stack” était utilisé jusqu’à React 15 inclus. Il se trouve dans src/renderers/shared/stack/reconciler.
\nPaul O’Shannessy a donné une conférence (en anglais) sur la construction de React à partir de zéro qui a largement inspiré ce document.
\nCe document et sa conférence sont des simplifications de la véritable base de code : en vous familiarisant avec ces deux sources, vous devriez mieux comprendre.
\nLe réconciliateur lui-même n’a pas d’API publique. Les moteurs de rendu comme React DOM et React Native l’utilisent pour mettre à jour efficacement l’interface utilisateur en fonction des composants React écrits par l’utilisateur.
\nIntéressons-nous à la première fois que vous montez un composant :
\nconst root = ReactDOM.createRoot(rootEl);\nroot.render(<App />);React DOM passera <App /> au réconciliateur. Rappelez-vous que <App /> est un élément React, c’est-à-dire une description de quoi afficher. Vous pouvez le considérer comme un simple objet :
console.log(<App />);\n// { type: App, props: {} }Le réconciliateur vérifiera si App est une classe ou une fonction.
Si App est une fonction, le réconciliateur appellera App(props) pour obtenir le rendu de l’élément associé.
Si App est une classe, le réconciliateur instanciera une App avec new App(props), appellera la méthode de cycle de vie componentWillMount(), puis appellera la méthode render() pour obtenir le rendu de l’élément.
Dans les deux cas, le réconciliateur saura quel élément « a été produit par le rendu » de App.
Ce processus est récursif. Le rendu de App peut produire un <Greeting />, celui de Greeting peut produire un <Button />, et ainsi de suite. Le réconciliateur « creusera » récursivement dans les composants définis par l’utilisateur, et saura ainsi ce que produit le rendu de chacun.
Vous pouvez imaginer ce processus comme un pseudo-code :
\nfunction isClass(type) {\n // Les sous-classes de React.Component ont ce drapeau\n return (\n Boolean(type.prototype) &&\n Boolean(type.prototype.isReactComponent)\n );\n}\n\n// Cette fonction prend en paramètre un élément React (par exemple <App />)\n// et renvoie un nœud DOM ou natif représentant l’arbre monté.\nfunction mount(element) {\n var type = element.type;\n var props = element.props;\n\n // Nous déterminerons l’élément rendu\n // soit en exécutant le type comme une fonction\n // soit en créant une instance puis en appelant render().\n var renderedElement;\n if (isClass(type)) {\n // Composant basé classe\n var publicInstance = new type(props);\n // Initialise les props\n publicInstance.props = props;\n // Appelle le cycle de vie si besoin\n if (publicInstance.componentWillMount) {\n publicInstance.componentWillMount();\n }\n // Obtient l’élément rendu en appelant render()\n renderedElement = publicInstance.render();\n } else {\n // Fonction composant\n renderedElement = type(props);\n }\n\n // Ce processus est récursif parce qu’un composant peut\n // renvoyer un élément avec un autre type de composant.\n return mount(renderedElement);\n\n // Remarque : cette implémentation est incomplète et la récursivité est infinie !\n // Ça gère uniquement les éléments comme <App /> ou <Button />.\n // Ça ne gère pas pour l’instant les éléments comme <div /> ou <p />.\n}\n\nvar rootEl = document.getElementById('root');\nvar node = mount(<App />);\nrootEl.appendChild(node);\n\nRemarque
\nC’est vraiment du pseudo-code. L’implémentation actuelle diffère pas mal. Ce code saturerait la pile car nous n’avons pas précisé de condition d’arrêt pour la récursivité.
\n
Récapitulons quelques idées clés dans l’exemple ci-dessus :
\nApp) et les props.App) peuvent être des classes ou des fonctions mais toutes « font un rendu » avec des éléments comme résultat.<App />).Ce processus serait inutile si nous n’affichions pas quelque chose à l’écran au final.
\nEn plus des composants définis par l’utilisateur (« composites »), les éléments React peuvent également représenter des composants pour des plates-formes spécifiques (« hôtes »). Par exemple, la méthode de rendu de Button pourrait renvoyer une <div />.
Si la propriété type de l’élément est une chaîne de caractères, il s’agit d’un élément hôte :
console.log(<div />);\n// { type: 'div', props: {} }Il n’y a aucun code défini par l’utilisateur associé aux éléments hôtes.
\nLorsque le réconciliateur rencontre un élément hôte, il laisse le moteur de rendu s’occuper du montage. Par exemple, React DOM créerait un nœud DOM.
\nSi l’élément hôte a des enfants, le réconciliateur les monte de manière récursive en suivant le même algorithme que celui décrit plus haut. Peu importe que les enfants soient hôtes (comme <div><hr /></div>), composites (comme <div><Button /></div>) ou un mélange des deux.
Les nœuds DOM produits par les composants enfants seront ajoutés au nœud DOM parent, et donc de manière récursive, l’ensemble de la structure DOM sera constituée.
\n\n\nRemarque
\nLe réconciliateur lui-même n’est pas lié au DOM. Le résultat exact du montage (parfois appelé “mount image” dans le code source) dépend du moteur de rendu, et donc peut être un nœud DOM (React DOM), une chaîne de caractères (React DOM Server) ou un nombre représentant une vue native (React Native).
\n
Si nous devions étendre le code pour gérer des éléments hôtes, il ressemblerait à ceci :
\nfunction isClass(type) {\n // Les sous-classes de React.Component ont ce drapeau\n return (\n Boolean(type.prototype) &&\n Boolean(type.prototype.isReactComponent)\n );\n}\n\n// Cette fonction gère uniquement les éléments avec un type composite.\n// Par exemple, elle gère <App /> et <Button />, mais pas une <div />.\nfunction mountComposite(element) {\n var type = element.type;\n var props = element.props;\n\n var renderedElement;\n if (isClass(type)) {\n // Composant basé classe\n var publicInstance = new type(props);\n // Initialise les props\n publicInstance.props = props;\n // Appelle le cycle de vie si besoin\n if (publicInstance.componentWillMount) {\n publicInstance.componentWillMount();\n }\n renderedElement = publicInstance.render();\n } else if (typeof type === 'function') {\n // Fonction composant\n renderedElement = type(props);\n }\n\n // C’est récursif mais nous atteindrons finalement le bas de la récursion lorsque\n // l’élément sera hôte (par exemple <div />) au lieu de composite (par exemple <App />) :\n return mount(renderedElement);\n}\n\n// Cette fonction gère uniquement les éléments avec un type hôte.\n// Par exemple, il gère <div /> et <p />, mais pas un <App />.\nfunction mountHost(element) {\n var type = element.type;\n var props = element.props;\n var children = props.children || [];\n if (!Array.isArray(children)) {\n children = [children];\n }\n children = children.filter(Boolean);\n\n // Ce bloc de code ne devrait pas être dans le réconciliateur.\n // Les différents moteurs de rendu peuvent initialiser les nœuds différemment.\n // Par exemple, React Native crée des vues iOS ou Android.\n var node = document.createElement(type);\n Object.keys(props).forEach(propName => {\n if (propName !== 'children') {\n node.setAttribute(propName, props[propName]);\n }\n });\n\n // Monte les enfants\n children.forEach(childElement => {\n // L’enfant peut être hôte (par exemple <div />) ou composite (par exemple <Button />).\n // Nous les monterons également de manière récursive :\n var childNode = mount(childElement);\n\n // Cette ligne de code est également spécifique au moteur de rendu.\n // Ce serait différent en fonction du moteur de rendu :\n node.appendChild(childNode);\n });\n\n // Renvoie le nœud DOM comme résultat de montage.\n // C’est ici que se termine la récursion.\n return node;\n}\n\nfunction mount(element) {\n var type = element.type;\n if (typeof type === 'function') {\n // Composants définis par l’utilisateur\n return mountComposite(element);\n } else if (typeof type === 'string') {\n // Composants spécifiques aux plates-formes\n return mountHost(element);\n }\n}\n\nvar rootEl = document.getElementById('root');\nvar node = mount(<App />);\nrootEl.appendChild(node);Ça fonctionne mais ça reste loin de la manière dont le réconciliateur est réellement implémenté. L’ingrédient clé manquant est la prise en charge des mises à jour.
\nLa principale caractéristique de React est que vous pouvez refaire tout le rendu sans recréer le DOM ni réinitialiser l’état :
\nroot.render(<App />);\n// Devrait réutiliser le DOM existant :\nroot.render(<App />);Cependant, notre implémentation ci-dessus sait uniquement monter l’arbre initial. Elle ne peut pas effectuer de mises à jour dans l’arborescence car elle ne stocke pas toutes les informations nécessaires, telles que toutes les références publicInstance ou les nœuds DOM qui correspondent aux composants.
La base de code du réconciliateur “stack” résout ce problème en faisant de la fonction mount() une méthode au sein d’une classe. Cette approche présente des inconvénients et nous allons dans la direction opposée pour la réécriture en cours du réconciliateur. Cependant, voici comment ça fonctionne dans le réconciliateur historique.
Plutôt que deux fonctions distinctes mountHost et mountComposite, nous créerons deux classes : DOMComponent et CompositeComponent.
Les deux classes ont un constructeur acceptant element, ainsi qu’une méthode mount() qui renvoie le nœud monté. Nous remplacerons la fonction racine mount() par une fabrique (factory, NdT) qui instanciera la bonne classe :
function instantiateComponent(element) {\n var type = element.type;\n if (typeof type === 'function') {\n // Composants définis par l’utilisateur\n return new CompositeComponent(element);\n } else if (typeof type === 'string') {\n // Composants spécifiques aux plates-formes\n return new DOMComponent(element);\n }\n}Tout d’abord, examinons l’implémentation de CompositeComponent :
class CompositeComponent {\n constructor(element) {\n this.currentElement = element;\n this.renderedComponent = null;\n this.publicInstance = null;\n }\n\n getPublicInstance() {\n // Pour les composants composites, exposons l’instance de la classe.\n return this.publicInstance;\n }\n\n mount() {\n var element = this.currentElement;\n var type = element.type;\n var props = element.props;\n\n var publicInstance;\n var renderedElement;\n if (isClass(type)) {\n // Composant basé classe\n publicInstance = new type(props);\n // Initialise les props\n publicInstance.props = props;\n // Appelle le cycle de vie si besoin\n if (publicInstance.componentWillMount) {\n publicInstance.componentWillMount();\n }\n renderedElement = publicInstance.render();\n } else if (typeof type === 'function') {\n // Fonction composant\n publicInstance = null;\n renderedElement = type(props);\n }\n\n // Sauvegarde l’instance publique\n this.publicInstance = publicInstance;\n\n // Construit l’instance interne de l’enfant en fonction de l’élément.\n // Ce sera un DOMComponent pour <div /> ou <p />,\n // et un CompositeComponent pour <App /> ou <Button /> :\n var renderedComponent = instantiateComponent(renderedElement);\n this.renderedComponent = renderedComponent;\n\n // Monte le résultat du rendu\n return renderedComponent.mount();\n }\n}Ce n’est pas très différent de notre implémentation précédente de mountComposite(), mais maintenant, nous pouvons sauver certaines informations, telles que this.currentElement, this.renderedComponent et this.publicInstance, pour les utiliser lors des mises à jour d’éléments.
Remarquez qu’une instance de CompositeComponent n’est pas la même chose qu’une instance du element.type fourni par l’utilisateur. CompositeComponent est un détail d’implémentation de notre réconciliateur et n’est jamais exposé à l’utilisateur. La classe définie par l’utilisateur est celle que nous avons lue dans element.type, et CompositeComponent crée une instance de celle-ci.
Pour éviter toute confusion, nous appellerons les instances de CompositeComponent et DOMComponent des « instances internes ». Elles existent pour nous permettre de leur associer des données durables. Seuls le moteur de rendu et le réconciliateur s’en servent.
En revanche, nous appelons une instance de classe définie par l’utilisateur « instance publique ». L’instance publique, c’est ce que vous voyez comme this dans render() et les autres méthodes de vos composants personnalisés.
La fonction mountHost() a été refactorisée pour devenir la méthode mount() dans la classe DOMComponent, et son code a des airs familiers :
class DOMComponent {\n constructor(element) {\n this.currentElement = element;\n this.renderedChildren = [];\n this.node = null;\n }\n\n getPublicInstance() {\n // Pour les composants DOM, expose uniquement le nœud du DOM.\n return this.node;\n }\n\n mount() {\n var element = this.currentElement;\n var type = element.type;\n var props = element.props;\n var children = props.children || [];\n if (!Array.isArray(children)) {\n children = [children];\n }\n\n // Crée et sauvegarde le nœud\n var node = document.createElement(type);\n this.node = node;\n\n // Initialise les attributs\n Object.keys(props).forEach(propName => {\n if (propName !== 'children') {\n node.setAttribute(propName, props[propName]);\n }\n });\n\n // Crée et sauvegarde les enfants contenus.\n // Chacun d’eux peut être un DOMComponent ou un CompositeComponent,\n // selon que le type de l’élément est une chaîne de caractères ou une fonction.\n var renderedChildren = children.map(instantiateComponent);\n this.renderedChildren = renderedChildren;\n\n // Collecte les nœuds DOM qui sont renvoyés lors du montage\n var childNodes = renderedChildren.map(child => child.mount());\n childNodes.forEach(childNode => node.appendChild(childNode));\n\n // Renvoie le nœud DOM comme résultat du montage\n return node;\n }\n}Après la refactorisation de mountHost(), la différence principale est que nous conservons this.node et this.renderedChildren, qui sont maintenant associés à l’instance interne du composant DOM. Nous les utiliserons également à l’avenir pour appliquer des mises à jour non destructives.
Par conséquent, chaque instance interne, composite ou hôte, pointe maintenant vers ses instances internes enfants. Pour vous aider à le visualiser, si une fonction composant <App> donne un composant basé classe <Button>, et qu’un Button donne une <div>, l’arbre des instances internes ressemblera à ceci :
[object CompositeComponent] {\n currentElement: <App />,\n publicInstance: null,\n renderedComponent: [object CompositeComponent] {\n currentElement: <Button />,\n publicInstance: [object Button],\n renderedComponent: [object DOMComponent] {\n currentElement: <div />,\n node: [object HTMLDivElement],\n renderedChildren: []\n }\n }\n}Dans le DOM, vous verriez uniquement la <div>. Pourtant, l’arbre d’instances internes contient tant les instances internes composites que celles hôtes.
Les instances internes composites ont besoin de stocker :
\nDOMComponent ou d’un CompositeComponent.Les instances internes hôtes ont besoin de stocker :
\nDOMComponent soit un CompositeComponent.Si vous avez du mal à imaginer la structure d’un arbre d’instances internes dans des applications plus complexes, React DevTools peut vous donner une bonne approximation, dans la mesure où il signale les instances hôtes en gris, et les instances composites en violet :
\n\n \n \n \n \n\n \n \n \n \n \nPour terminer cette refactorisation, nous allons introduire une fonction qui monte une arbre complet dans un nœud conteneur, tout comme root.render(). Elle renvoie une instance publique, là aussi comme root.render() :
function mountTree(element, containerNode) {\n // Crée une instance interne racine\n var rootComponent = instantiateComponent(element);\n\n // Monte le composant racine dans le conteneur\n var node = rootComponent.mount();\n containerNode.appendChild(node);\n\n // Renvoie l’instance publique fournie\n var publicInstance = rootComponent.getPublicInstance();\n return publicInstance;\n}\n\nvar rootEl = document.getElementById('root');\nmountTree(<App />, rootEl);Maintenant que nous avons des instances internes qui conservent leurs enfants et les nœuds DOM, nous pouvons implémenter le démontage. Pour un composant composite, le démontage appelle une méthode de cycle de vie et opère récursivement.
\nclass CompositeComponent {\n\n // ...\n\n unmount() {\n // Appelle la méthode de cycle de vie si besoin\n var publicInstance = this.publicInstance;\n if (publicInstance) {\n if (publicInstance.componentWillUnmount) {\n publicInstance.componentWillUnmount();\n }\n }\n\n // Démonte l’unique composant affiché\n var renderedComponent = this.renderedComponent;\n renderedComponent.unmount();\n }\n}Pour DOMComponent, le démontage appelle celui de chaque enfant :
class DOMComponent {\n\n // ...\n\n unmount() {\n // Démonte tous les éléments enfants\n var renderedChildren = this.renderedChildren;\n renderedChildren.forEach(child => child.unmount());\n }\n}En pratique, le démontage des composants DOM enlève également les écouteurs d’événements et efface certains caches, mais nous ignorerons ces détails.
\nNous pouvons maintenant ajouter une nouvelle fonction racine appelée unmountTree(containerNode), semblable à ReactDOM.unmountComponentAtNode() :
function unmountTree(containerNode) {\n // Lit l’instance interne depuis un nœud DOM :\n // (Ça ne fonctionne pas encore, il faudra changer mountTree() pour le stocker.)\n var node = containerNode.firstChild;\n var rootComponent = node._internalInstance;\n\n // Démonte l’arbre et efface le conteneur\n rootComponent.unmount();\n containerNode.innerHTML = '';\n}Pour que ça fonctionne, nous devons lire une instance interne racine à partir d’un nœud DOM. Nous modifierons mountTree() pour ajouter la propriété _internalInstance au nœud DOM racine. Nous apprendrons aussi à mountTree() à détruire n’importe quel arbre existant, donc nous pourrons l’appeler plusieurs fois :
function mountTree(element, containerNode) {\n // Détruit un éventuel arbre existant\n if (containerNode.firstChild) {\n unmountTree(containerNode);\n }\n\n // Crée l’instance interne racine\n var rootComponent = instantiateComponent(element);\n\n // Monte le composant racine dans un conteneur\n var node = rootComponent.mount();\n containerNode.appendChild(node);\n\n // Sauvegarde une référence à l’instance interne\n node._internalInstance = rootComponent;\n\n // Renvoie l’instance publique fournie\n var publicInstance = rootComponent.getPublicInstance();\n return publicInstance;\n}À présent, l’exécution répétée de unmountTree() ou de mountTree() supprime l’ancien arbre et exécute la méthode de cycle de vie componentWillUnmount() sur les composants.
Dans la section précédente, nous avons implémenté le démontage. Cependant, React ne serait pas très utile si à chaque modification de prop, l’arbre entier était démonté puis remonté. Le but du réconciliateur est de réutiliser dans la mesure du possible les instances existantes afin de préserver le DOM et l’état local :
\nvar rootEl = document.getElementById('root');\n\nmountTree(<App />, rootEl);\n// Devrait réutiliser le DOM existant :\nmountTree(<App />, rootEl);Nous allons ajouter une méthode supplémentaire au contrat de nos instances internes. En plus de mount() et unmount(), DOMComponent et CompositeComponent implémenteront une nouvelle méthode appelée receive(nextElement) :
class CompositeComponent {\n // ...\n\n receive(nextElement) {\n // ...\n }\n}\n\nclass DOMComponent {\n // ...\n\n receive(nextElement) {\n // ...\n }\n}Son travail consiste à faire tout le nécessaire pour mettre à jour le composant (et ses enfants) avec la description fournie par nextElement.
C’est la partie qui est souvent décrite comme la « comparaison de DOM virtuel » (virtual DOM diffing, NdT), même si ça consiste en réalité à parcourir récursivement l’arbre interne pour permettre à chaque instance interne de recevoir une mise à jour.
\nLorsqu’un composant composite reçoit un nouvel élément, nous exécutons la méthode de cycle de vie componentWillUpdate().
Ensuite nous rafraîchissons le composant avec les nouvelles props et récupérons le prochain élément issu du rendu :
\nclass CompositeComponent {\n\n // ...\n\n receive(nextElement) {\n var prevProps = this.currentElement.props;\n var publicInstance = this.publicInstance;\n var prevRenderedComponent = this.renderedComponent;\n var prevRenderedElement = prevRenderedComponent.currentElement;\n\n // Met à jour l’élément *associé*\n this.currentElement = nextElement;\n var type = nextElement.type;\n var nextProps = nextElement.props;\n\n // Détermine quel est le prochain résultat de render()\n var nextRenderedElement;\n if (isClass(type)) {\n // Composant basé classe\n // Appelle le cycle de vie si besoin\n if (publicInstance.componentWillUpdate) {\n publicInstance.componentWillUpdate(nextProps);\n }\n // Met à jour les props\n publicInstance.props = nextProps;\n // Rafraîchit\n nextRenderedElement = publicInstance.render();\n } else if (typeof type === 'function') {\n // Fonction composant\n nextRenderedElement = type(nextProps);\n }\n\n // ...Ensuite, nous pouvons regarder le type de l’élément produit. Si le type n’a pas changé depuis le dernier rendu, le composant sous-jacent peut être mis à jour directement.
Par exemple, s’il renvoie <Button color=\"red\" /> la première fois et <Button color=\"blue\" /> la seconde fois, nous pouvons simplement dire à l’instance interne correspondante de recevoir (receive()) l’élément mis à jour :
// ...\n\n // Si le type de l’élément affiché n’a pas changé,\n // réutilise l’instance du composant existant et sort.\n if (prevRenderedElement.type === nextRenderedElement.type) {\n prevRenderedComponent.receive(nextRenderedElement);\n return;\n }\n\n // ...Cependant, si l’élément mis à jour a un type différent de celui affiché jusqu’ici, nous ne pouvons pas mettre à jour l’instance interne. Un <button> ne peut pas simplement « devenir » un <input>.
Dans ce cas, nous devons démonter l’instance interne existante et monter la nouvelle correspondant au type du nouvel élément. Par exemple, voici ce qui se produit lorsqu’un composant ayant précédemment affiché un <button /> affiche désormais un <input /> :
// ...\n\n // Si nous arrivons jusqu’ici, nous devons démonter le composant\n // précédemment monté, monter le nouveau et échanger leurs nœuds.\n\n // Récupère l’ancien nœud car il devra être remplacé\n var prevNode = prevRenderedComponent.getHostNode();\n\n // Démonte l’ancien élément enfant et en monte un nouveau\n prevRenderedComponent.unmount();\n var nextRenderedComponent = instantiateComponent(nextRenderedElement);\n var nextNode = nextRenderedComponent.mount();\n\n // Remplace la référence à l’enfant\n this.renderedComponent = nextRenderedComponent;\n\n // Remplace l’ancien nœud par le nouveau.\n // Remarque : il s’agit d’un code spécifique au moteur de rendu et\n // idéalement il devrait vivre en dehors de CompositeComponent :\n prevNode.parentNode.replaceChild(nextNode, prevNode);\n }\n}En résumé, lorsqu’un composant composite reçoit un nouvel élément, il peut soit déléguer la mise à jour à son instance interne issue du rendu précédent, soit la démonter et en monter une nouvelle en remplacement.
\nIl existe un autre cas dans lequel un composant va être remonté plutôt que de recevoir un élément : lorsque la key de cet élément a été modifiée. Nous ne voyons pas la gestion des key dans ce document, car elle ajoute une complexité supplémentaire à un tutoriel déjà velu.
Remarquez que nous devons encore ajouter une méthode appelée getHostNode() à l’instance interne afin qu’il soit possible de localiser le nœud spécifique à la plate-forme et de le remplacer lors de la mise à jour. Son implémentation est simple pour les deux classes :
class CompositeComponent {\n // ...\n\n getHostNode() {\n // Demande au composant issu du rendu de le fournir.\n // Ça analysera récursivement tous les composites.\n return this.renderedComponent.getHostNode();\n }\n}\n\nclass DOMComponent {\n // ...\n\n getHostNode() {\n return this.node;\n }\n}Les implémentations de composant hôte, comme DOMComponent, font leurs mises à jour différemment. À la réception d’un élément, ils ont besoin de mettre à jour la vue spécifique à la plate-forme sous-jacente. Dans le cas de React DOM, ça implique de mettre à jour les attributs DOM :
class DOMComponent {\n // ...\n\n receive(nextElement) {\n var node = this.node;\n var prevElement = this.currentElement;\n var prevProps = prevElement.props;\n var nextProps = nextElement.props;\n this.currentElement = nextElement;\n\n // Supprime les anciens attributs.\n Object.keys(prevProps).forEach(propName => {\n if (propName !== 'children' && !nextProps.hasOwnProperty(propName)) {\n node.removeAttribute(propName);\n }\n });\n // Initialise les nouveaux attributs.\n Object.keys(nextProps).forEach(propName => {\n if (propName !== 'children') {\n node.setAttribute(propName, nextProps[propName]);\n }\n });\n\n // ...Ensuite, les composants hôtes doivent mettre à jour leurs enfants. Contrairement aux composants composites, ils peuvent posséder plusieurs enfants.
\nDans cet exemple simplifié, nous utilisons un tableau d’instances internes et itérons dessus. Si le type reçu des instances internes correspond au type précédent, nous les mettons à jour, sinon nous les remplaçons. Le vrai réconciliateur prend également en compte la key de l’élément et détecte les déplacements en plus des insertions et des suppressions, mais nous omettons cette logique.
Nous collectons les opérations DOM sur les enfants dans une liste, afin de pouvoir les exécuter par lot :
\n // ...\n\n // Ce sont des tableaux d’éléments React :\n var prevChildren = prevProps.children || [];\n if (!Array.isArray(prevChildren)) {\n prevChildren = [prevChildren];\n }\n var nextChildren = nextProps.children || [];\n if (!Array.isArray(nextChildren)) {\n nextChildren = [nextChildren];\n }\n // Ce sont des tableaux d’instances internes :\n var prevRenderedChildren = this.renderedChildren;\n var nextRenderedChildren = [];\n\n // Au fil de l’itération sur les enfants, nous ajouterons des opérations dans le tableau.\n var operationQueue = [];\n\n // Remarque : la section ci-dessous est extrêmement simplifiée !\n // Elle ne gère pas le réordonnancement, les enfants avec des trous ou les clés (`key`).\n // Elle existe uniquement pour illustrer le flux général, pas les détails.\n\n for (var i = 0; i < nextChildren.length; i++) {\n // Essaie de récupérer une instance interne existante pour cet enfant\n var prevChild = prevRenderedChildren[i];\n\n // S’il n’y a aucune instance interne pour cet index,\n // c’est qu’un enfant a été ajouté à la fin. Nous créons une nouvelle\n // instance interne, nous la montons, et nous utilisons son nœud.\n if (!prevChild) {\n var nextChild = instantiateComponent(nextChildren[i]);\n var node = nextChild.mount();\n\n // Enregistre le besoin d'ajouter un nœud\n operationQueue.push({type: 'ADD', node});\n nextRenderedChildren.push(nextChild);\n continue;\n }\n\n // Nous ne pouvons mettre à jour l’instance que si le type de son élément est identique.\n // Par exemple, <Button size=\"small\" /> peut être mis à jour par\n // <Button size=\"large\" /> mais pas par un <App />.\n var canUpdate = prevChildren[i].type === nextChildren[i].type;\n\n // Si nous ne pouvons pas mettre à jour une instance existante, nous devons la démonter\n // et monter une nouvelle à la place.\n if (!canUpdate) {\n var prevNode = prevChild.getHostNode();\n prevChild.unmount();\n\n var nextChild = instantiateComponent(nextChildren[i]);\n var nextNode = nextChild.mount();\n\n // Enregistre le besoin de remplacer un nœud\n operationQueue.push({type: 'REPLACE', prevNode, nextNode});\n nextRenderedChildren.push(nextChild);\n continue;\n }\n\n // Si nous pouvons mettre à jour une instance existante,\n // laissons-la simplement recevoir l’élément cible et gérer sa propre mise à jour.\n prevChild.receive(nextChildren[i]);\n nextRenderedChildren.push(prevChild);\n }\n\n // Enfin, démonte tous les enfants qui n’existent pas :\n for (var j = nextChildren.length; j < prevChildren.length; j++) {\n var prevChild = prevRenderedChildren[j];\n var node = prevChild.getHostNode();\n prevChild.unmount();\n\n // Enregistre le besoin de supprimer un nœud\n operationQueue.push({type: 'REMOVE', node});\n }\n\n // Actualise la liste des enfants issus du rendu.\n this.renderedChildren = nextRenderedChildren;\n\n // ...Pour finir, nous exécutons les opérations sur le DOM. Encore une fois, le vrai code du réconciliateur est plus complexe car il gère également les déplacements :
\n // ...\n\n // Traite les opérations dans la file d’attente\n while (operationQueue.length > 0) {\n var operation = operationQueue.shift();\n switch (operation.type) {\n case 'ADD':\n this.node.appendChild(operation.node);\n break;\n case 'REPLACE':\n this.node.replaceChild(operation.nextNode, operation.prevNode);\n break;\n case 'REMOVE':\n this.node.removeChild(operation.node);\n break;\n }\n }\n }\n}Et c’est tout pour la mise à jour des composants hôtes.
\nMaintenant que CompositeComponent et DOMComponent implémentent la méthode receive(nextElement), nous pouvons modifier la fonction racine mountTree() pour l’utiliser lorsque le type de l’élément est identique à celui de la dernière fois :
function mountTree(element, containerNode) {\n // Vérifie l'existence d’un arbre\n if (containerNode.firstChild) {\n var prevNode = containerNode.firstChild;\n var prevRootComponent = prevNode._internalInstance;\n var prevElement = prevRootComponent.currentElement;\n\n // Si possible, réutilise le composant racine existant\n if (prevElement.type === element.type) {\n prevRootComponent.receive(element);\n return;\n }\n\n // Autrement, démonte l’arborescence existante\n unmountTree(containerNode);\n }\n\n // ...\n\n}Désormais, appeler deux fois mountTree() avec le même type n’est plus destructif :
var rootEl = document.getElementById('root');\n\nmountTree(<App />, rootEl);\n// Réutilise le DOM existant :\nmountTree(<App />, rootEl);Et voilà les bases du fonctionnement interne de React.
\nCe document est simplifié par rapport au vrai code. Il y a quelques aspects importants que nous n’avons pas abordés :
\nnull et le réconciliateur peut gérer des « emplacements vides » dans les tableaux et le résultat du rendu.key des éléments, et l’utilise pour déterminer quelle instance interne correspond à quel élément dans un tableau. Une grande partie de la complexité de la véritable implémentation de React est liée à ça.null.ReactDOMComponent pour l’implémentation de l’instance interne hôte.ReactMultiChild, utilisé par les implémentations de la classe d’instance interne hôte dans React DOM comme dans React Native.setState() dans les composants composites. Les mises à jour d’état multiples dans les gestionnaires d’événements sont regroupées en lot pour une mise à jour unique.componentDidMount() et componentDidUpdate(), sont rassemblées dans des « files d’attente de fonctions de rappel » et exécutées en un seul lot.ReactMount est l’endroit où réside le code équivalent aux mountTree() et unmountTree() de ce tutoriel. Il s’occupe du montage et du démontage des composants racines. ReactNativeMount est son homologue pour React Native.ReactDOMComponent est l’équivalent de DOMComponent dans ce tutoriel. Il implémente la classe de composant hôte pour le moteur de rendu de React DOM. ReactNativeBaseComponent est son équivalent React Native.ReactCompositeComponent est l’équivalent de CompositeComponent dans ce tutoriel. Il gère l’appel des composants définis par l’utilisateur et la maintenance de leur état local.instantiateReactComponent contient le code qui sélectionne la classe d’instance interne appropriée pour construire un élément. C’est l’équivalent de instantiateComponent() dans ce tutoriel.ReactReconciler est un enrobage avec les méthodes mountComponent(), receiveComponent() et unmountComponent(). Il appelle les implémentations sous-jacentes des instances internes, mais contient en prime du code de gestion partagé par toutes ces implémentations.ReactChildReconciler implémente la logique de montage, de mise à jour et de démontage des enfants en fonction de la key de leurs éléments.ReactMultiChild implémente le traitement de la file d’attente des opérations pour les insertions, les suppressions et les déplacements d’enfants indépendamment du moteur de rendu.mount(), receive() et unmount() sont nommées en réalité mountComponent(), receiveComponent() et unmountComponent() dans la base de code React pour des raisons historiques, mais elles reçoivent des éléments._currentElement. Elles sont considérées dans la base de code comme des champs publics en lecture seule.Le réconciliateur “stack” a des limitations intrinsèques, comme le fait qu’il soit synchrone et incapable d’interrompre le travail ou de le découper en plusieurs morceaux. Le nouveau réconciliateur “fiber” a une architecture complètement différente. À partir de React 16, il remplace le réconciliateur “stack”.
\nLisez la page suivante pour en apprendre davantage sur les principes de conception que nous utilisons pour le développement de React.
","frontmatter":{"title":"Notes d’implémentation","next":"design-principles.html","prev":"codebase-overview.html"},"fields":{"path":"content/docs/implementation-notes.md","slug":"docs/implementation-notes.html"}}},"pageContext":{"slug":"docs/implementation-notes.html"}},"staticQueryHashes":[]}