Réponses aux méthodes d'optimisation des performances pour les composants React-js tutoriel-php.cn

Ne gaspillez pas votre énergie d’optimisation des performances sur du code qui n’améliore que peu les performances globales. Il n’est pas trop tôt pour optimiser les éléments qui ont un impact clé sur les performances. Car la partie la plus critique qui affecte les performances concerne souvent le cœur de la solution et détermine l’architecture globale, qui sera encore plus impliquée lorsqu’elle devra être modifiée à l’avenir.

1. Optimisation des performances d'un seul composant React

React utilise Virtual DOM pour améliorer les performances de rendu, bien que chaque mise à jour de page soit la plus importante Re-rendu du composant, mais il ne supprime pas tout le contenu du rendu précédent et ne recommence pas. Avec l'aide de Virtual DOM, React peut calculer la modification minimale de l'arborescence DOM par défaut. 🎜>

Cependant, bien que Virtual DOM puisse réduire au minimum la quantité de chaque opération DOM, calculer et comparer Virtual DOM reste un processus compliqué

Bien sûr, si vous pouvez calculer Virtual ; DOM avant de démarrer Tant que l'on estime que le résultat du rendu ne changera pas, il n'est pas nécessaire d'effectuer un calcul et une comparaison du Virtual DOM, et la vitesse sera plus rapide.

2. L'implémentation par défaut de ShouldComponentUpdate

Puisqu'il peut être déterminé que le résultat du rendu du composant ne changera pas avant de commencer le calcul le DOM Virtuel, Pour empêcher le rendu et améliorer les performances, alors on pense naturellement à utiliser ShouldComponentUpdate(nextProp,nextState)

La fonction ShouldComponentUpdate est appelée avant la fonction de rendu pour déterminer "quand il n'est pas nécessaire de re-render";

Renvoie une valeur booléenne pour déterminer si la mise à jour continue. La valeur par défaut renvoie true. Si false est renvoyé, la mise à jour sera interrompue ;

shouldComponentUpdate(nextProp,nextState){
  return (nextProp.completed !== this.props.completed) ||
    (nextProp.text !== this.props.text)
}

Copier après la connexion

où nextProps est Pour les accessoires passés dans cette mise à jour, pour ce composant, les seuls accessoires qui affectent le contenu du rendu sont terminés et le texte Tant que ces deux accessoires n'ont pas changé, ShouldComponentUpdate peut retourner. false pour éviter les mises à jour inutiles

Cependant, la comparaison ci-dessus n'est qu'une « comparaison superficielle ». Si le type est un type de base, tant que les valeurs sont les mêmes, alors la « comparaison superficielle ». comparaison'

considérera également que les deux sont identiques :

Alors, que se passe-t-il si le type d'accessoire est un objet complexe ?

Pour les objets complexes, la méthode de « comparaison superficielle » vérifie uniquement si les deux accessoires sont des références au même objet. Sinon, même si le contenu des objets est exactement le même, ils le seront. considéré comme différent. Utilisez ensuite la « comparaison approfondie » : Mais la structure de l'objet est imprévisible. Si vous effectuez une « comparaison approfondie » sur chaque champ de manière récursive, cela rendra non seulement le code plus complexe, mais peut également entraîner des problèmes de performances.

Donc, si vous souhaitez déterminer que les accessoires des types d'objet avant et après sont les mêmes, vous devez vous assurer que les accessoires pointent vers le même objet JavaScript :

<Foo styleProp = {{color: "red"}}>

Copier après la connexion

Pour éviter d'utiliser la méthode de saisie ci-dessus, l'objet {color: "red"} sera recréé à chaque fois qu'il sera rendu, et l'adresse de référence sera différente à chaque fois. time, ce qui fera que le styleProp sera différent à chaque fois.

const footStyle = {color: "red"};//确保这个初始化只执行一次，不要放在render函数中
<Foo styleProp = {footStyle}>

Copier après la connexion

Utilisez le « mode singleton » pour vous assurer que le styleProp a transmis des points au même objet

Et si est une fonction ?

<Foo onToggle={() => onToggleTodo(item.id)}/>

Copier après la connexion

Vous devez éviter d'utiliser le mode de transfert de fonction ci-dessus, car l'affectation ici est une fonction anonyme, et elle est générée lors de l'affectation, c'est-à-dire Dire que chaque rendu produit une nouvelle fonction, c'est là le problème.

Et s'il y a beaucoup d'accessoires à passer ?

Eh bien~~Si vous utilisez React-Redux, il existe une implémentation par défaut de ShouldComponentUpdate.

3. Optimisation des performances de plusieurs composants React

Lorsqu'un composant React est chargé, mis à jour et déchargé, une séquence de fonctions de cycle de vie des composants sera être appelé. Cependant, ces fonctions de cycle de vie sont destinées à une fonction spécifique du composant React. Dans une application, de nombreux composants React sont combinés de haut en bas, et le processus de rendu entre eux est plus compliqué.

Le processus de rendu du même composant doit également prendre en compte trois processus : la phase de chargement, la phase de mise à jour et la phase de déchargement.

Pour la phase de chargement, le composant doit être complètement rendu quoi qu'il arrive. À un moment donné, tous les sous-composants de ce composant React doivent passer par le cycle de vie de chargement du composant React, il n'y a donc pas beaucoup d'optimisation à faire.

Pour la phase de désinstallation, il n'y a qu'une seule fonction de cycle de vie ComponentWillUnmount. Cette fonction nettoie uniquement le traitement et la surveillance des événements ajoutés par ComponentDidMount et d'autres travaux de finition, il n'y a donc pas de place pour l'optimisation ; 🎜>

4. Processus de réconciliation dans la phase de mise à jour de React

Pendant le processus de mise à jour du composant, un DOM virtuel mis à jour sera construit et comparé au précédent. Virtual DOM , afin de trouver les différences et d'utiliser le moins d'opérations DOM pour mettre à jour

Processus de réconciliation : c'est-à-dire le processus de recherche des différences dans le DOM virtuel dans la mise à jour React, comparant généralement deux arborescences de N nœuds La complexité temporelle de l'algorithme est O(n*3). Si vous utilisez directement la comparaison par défaut

, s'il y a trop de nœuds, il y aura trop d'opérations nécessaires, et cela est impossible pour React d'adopter cet algorithme ;

La complexité temporelle de l'algorithme réellement utilisé par React est O(N) (la complexité temporelle est juste une estimation de l'ordre de grandeur des opérations d'instruction requises par un algorithme dans le meilleur et le pire des cas)

React的Reconciliation算法并不复杂，首先检查两个树形的根节点的类型是否相同，根据相同或者不同有不同的处理方式：

节点类型不同的情况

如果树形节点的类型不相同，那就意味着改动很大，直接认为原来的那个树形结构已经没用，可以扔掉，需要从新构建DOM树，原有的树形上的React组件便会经历“卸载”的生命周期；

也就是说，对于Virtual DOM树这是一个“更新”过程，但是却可能引发这个树结构上某些组件的“装载”和“卸载”过程
如：

更新前

 <p>
  <Todos />
 </p>

Copier après la connexion

我们想要更新成这样：

 <span>
   <Todos />
 </span>

Copier après la connexion

>1. 那么在作比较的时候，一看根节点原来是p，新的是span，类型就不一样了，那么这个算法就废弃之前的p包括里面的所有子节点，从新构建一个span节点和子节点；

>2. 很明显因为根节点不同就将所有的子节点从新构建，这很浪费，但是为了避免O(N*3)的时间复杂度，React这能选择这种比较简单、快捷的方法；

>3. 所以，作为开发者，我们一定要避免上面的浪费的情景出现

节点类型相同的情况

如果两个节点类型相同时，对于DOM元素，React会保留节点对应的DOM元素，只对其节点的属性和内容做对比，然后只修改更新的部分；

节点类型相同时，对于React组件类型，React做得是根据新节点的props去更新节点的组件实例，引发组件的更新过程；

在处理完根节点对比后，React的算法会对根节点的每一个子节点重复一样的操作

多个相同子组件的情况

如果最初组件状态为：

<ul>
  <TodoItem text = "First" />
  <TodoItem text = "Second" />

</ul>

Copier après la connexion

更新后为：

<ul>
  <TodoItem text = "First" />
  <TodoItem text = "Second" />
  <TodoItem text = "Third" />
</ul>

Copier après la connexion

那么React会创建一个新的TodoItem组件实例，而前两个则进行正常的更新过程但是，如果更新后为：

<ul>
  <TodoItem text = "Zero" />
  <TodoItem text = "First" />
  <TodoItem text = "Second" />

</ul>

Copier après la connexion

（这将暴露一个问题）理想处理方式是，创建一个新的TodoItem组件实例放在第一位，后两个进入自然更新过程
但是要让react按照这种方式，就必须找两个子组件的不同之处，而现有计算两个序列差异的算法时间是O(N*2),显然则
不适合对性能要求很高的场景，所以React选择了一个看起来很傻的办法，即挨个比较每个子组件；

React首先认为把text为First的组件的text改为Zero,Second的改为First，最后创建一个text为Second的组件，这样便会破原有的两个组件完成一个更新过程，并创建一个text为Second的新组件

这显然是一个浪费，React也意到，并提供了方克服，不过需要开发人员提供一点帮助，这就是key

Key的使用

key属性可以明确的告诉React每个组件的唯一标识

如果最初组件状态为：

<ul>
  <TodoItem key={1} text = "First" />
  <TodoItem key={2} text = "Second" />

</ul>

Copier après la connexion

更新后为：

<ul>
  <TodoItem key={0} text = "Zero" />
  <TodoItem key={1} text = "First" />
  <TodoItem key={2} text = "Second" />
</ul>

Copier après la connexion

因为有唯一标识key,React可以根据key值，知道现在的第二和第三个组件就是之前的第一和第二个，便用原来的props启动更新过程，这样shouldComponentUpdate就会发生作用，避免无谓的更新；

注意：因为作为组件的唯一标识，所以key必须唯一，且不可变

下面的代码是错误的例子：

<ul>
  todos.map((item,index) => {
      <TodoItem
        key={index}
        text={item.text}
      />
    })
</ul>

Copier après la connexion

使用数组下标作为key值，看起来唯一，但不稳定，因为随着todos数组值的不同，同样一个组件实例在不同的更新过程中数组的下标完全可能不同，把下标当做可以就会让React乱套，记住key不仅要唯一还要确保稳定不可变

需要注意：虽然key是一个prop，但是接受key的组件不能读取key的值，因为key和ref是React保留的两个特殊prop，并没有预期让组将直接访问。