Le fonctionnaire React docs Etat qui « React.PureComponentest shouldComponentUpdate()seulement compare les objets » peu profondément, et conseille contre ce si l' état est « profond ».

Compte tenu de cela, y a-t-il une raison pour laquelle on devrait préférer React.PureComponentlors de la création de composants React?

Questions :

• y a-t-il un impact sur les performances React.Componentque nous pourrions envisager d' utiliser React.PureComponent?
• Je devine shouldComponentUpdate()de PureComponentfonction fonctionne uniquement des comparaisons peu profondes. Si tel est le cas, cette méthode ne peut-elle pas être utilisée pour des comparaisons plus approfondies?
• "De plus, React.PureComponents shouldComponentUpdate()ignore les mises à jour des accessoires pour l'ensemble du sous-arbre du composant" - Cela signifie-t-il que les modifications des accessoires sont ignorées?

La question a surgi de la lecture de ce blog moyen , si cela aide.

La principale différence entre React.PureComponentet React.Componentest PureComponentune comparaison superficielle des changements d'état. Cela signifie que lors de la comparaison de valeurs scalaires, il compare leurs valeurs, mais lors de la comparaison d'objets, il ne compare que les références. Cela permet d'améliorer les performances de l'application.

Vous devez choisir React.PureComponentquand vous pouvez satisfaire l'une des conditions ci-dessous.

• State / Props doit être un objet immuable
• Les états / accessoires ne doivent pas avoir de hiérarchie
• Vous devez appeler forceUpdatelorsque les données changent

Si vous utilisez, React.PureComponentvous devez vous assurer que tous les composants enfants sont également purs.

Y a-t-il un impact sur les performances dans l'utilisation de React.component que nous pourrions envisager d'utiliser React.PureComponent?

Oui, cela augmentera les performances de votre application (en raison d'une comparaison superficielle)

Je suppose que shouldComponentUpdate () de Purecomponent n'effectue que des comparaisons superficielles. Si tel est le cas, cette méthode ne peut-elle pas être utilisée pour des comparaisons plus approfondies?

Vous l'avez deviné correctement. Vous pouvez l'utiliser si vous remplissez l'une des conditions que j'ai mentionnées ci-dessus.

"De plus, shouldComponentUpdate () de React.PureComponent ignore les mises à jour des accessoires pour la sous-arborescence du composant entier" - Cela signifie-t-il que les changements d'accessoires sont ignorés?

Oui, les changements d'accessoires seront ignorés s'il ne peut pas trouver de différence dans une comparaison superficielle.

Componentet PureComponentavoir une différence

PureComponentest exactement la même que Componentsauf qu'il gère la shouldComponentUpdateméthode pour vous.

Lorsque les accessoires ou l'état changent, PureComponentfera une comparaison superficielle des accessoires et de l'état. Componentd'autre part, ne comparera pas les accessoires et l'état actuels au prochain prêt à l'emploi. Ainsi, le composant sera rendu de nouveau par défaut à chaque shouldComponentUpdateappel.

Comparaison superficielle

Lorsque vous comparez les accessoires et l'état précédents au suivant, une comparaison superficielle vérifiera que les primitives ont la même valeur (par exemple, 1 est égal à 1 ou que true est égal à true) et que les références sont les mêmes entre des valeurs javascript plus complexes comme des objets et des tableaux.

Source: https://codeburst.io/when-to-use-component-or-purecomponent-a60cfad01a81

La principale différence, à mon avis, est qu'un composant se redirige à chaque fois que ses parents se redirigent, que les accessoires et l'état du composant aient changé.

Un composant pur, en revanche, ne sera pas rendu à nouveau si ses parents sont rendus, à moins que les accessoires (ou l'état) du composant pur n'aient changé.

Par exemple, disons que nous avons une arborescence de composants avec une hiérarchie à trois niveaux: parent, enfants et petits-enfants.

Lorsque les accessoires du parent sont modifiés de manière à ce que les accessoires d'un seul enfant soient modifiés, alors:

• si tous les composants sont des composants normaux, alors l’arborescence complète des composants
• si tous les enfants et petits-enfants sont de purs composants, alors un seul enfant sera rendu, et un ou tous ses petits-enfants, selon que leurs accessoires ont été modifiés. S'il existe de nombreux composants dans cette arborescence de composants, cela peut signifier une augmentation significative des performances.

Parfois, cependant, l'utilisation de composants purs n'aura aucun impact. J'ai eu un tel cas lorsque le parent a reçu ses accessoires d'un magasin redux et devait effectuer un calcul complexe des accessoires de ses enfants. Le parent a utilisé une liste plate pour rendre ses enfants.

Le résultat a été que chaque fois qu'il y avait même un petit changement dans le magasin redux, l'ensemble complet des listes de données des enfants à plat a été recalculé. Cela signifiait que pour chaque composant de l'arborescence, les accessoires étaient de nouveaux objets, même si les valeurs ne changeaient pas.

Dans ce cas, les composants purs n'aident pas, et l'augmentation des performances ne peut être obtenue qu'en utilisant des composants réguliers et en archivant les enfants, dans shouldComponentUpdate, si un nouveau rendu est nécessaire.