Raisonnement sur la mauvaise utilisation de useEffect

Le hook le plus mal utilisé dans React est, bien sûr, useEffect. Nous avons plusieurs raisons à cela, pas une seule. Explorons chacun d'eux, de mon point de vue.

Héritage du cycle de vie

Donc, l'une des raisons pour lesquelles je pense que cela a plus d'impact est que, à l'époque des pré-crochets, nous utilisions des cours. Pour ceux qui ont commencé à utiliser React au cours de cette période, il est utilisé pour utiliser les méthodes de cycle de vie et this.state. J'ai écrit un peu à ce sujet dans cet article. Il y a des gens qui manquent la période des classes anciennes mais dorées et apprécient sa simplicité et sa franchise. C'est un modèle qui correspond assez bien aux connaissances communes des programmeurs en général, qui apprennent la programmation orientée objet et impérative, et la structure mentale se connecte simplement à ce modèle.

Puis ils ont ajouté des crochets.

Changement mental de paradigme

Le problème est le changement de paradigme qui s'est produit. Les programmeurs en général sont très familiers avec les paradigmes impératifs et orientés objet, ils sont couramment enseignés dans les collèges et les cours, principalement celui de l'impératif, suit le flux commun de pensée d'un être humain.

Lorsque vous passez à différents paradigmes comme la programmation fonctionnelle, vous êtes confronté à une façon de penser inversée, qui n'est pas si proche de la pensée commune. Cette « réversion » rend la compréhension plus difficile.

La programmation réactive souffre du même problème. C’est un changement d’une manière active à une manière passive de programmer. Nous le voyons avec une mauvaise utilisation de useEffect.

La plupart des "ERREURS" sont des synchronisations d'état. Ainsi, le développeur utilise useEffect pour suivre un état ou un accessoire et, sur la base d'une certaine logique, pour changer l'état. Ce cas révèle la façon de penser inverse dont nous avons besoin ici.

En programmation POO et impérative, vous êtes actif, effectuant les changements et la logique de manière proactive. La réactivité est basée sur l'inverse, vous réagissez à une chance, et déclarez les calculs que vous souhaitez que le système fasse lorsque l'état change.

Pour la plupart des utilisateurs, définir activement le nouvel état sur useEffect est le moyen direct, l'état a changé, vous devez donc suivre manuellement le changement et mettre à jour les autres états avec. Les documents disent que ce n’est PAS recommandé, mais il n’y a aucune raison claire à cela.

Dériver dans React est la méthode recommandée non seulement pour des raisons de performances, mais aussi pour des raisons conceptuelles. React est une machine de dérivation, et le résultat, en fin de compte, est la dérivation de l'interface utilisateur. Vous n'avez pas besoin de gérer activement ces transitions d'état et ces recalculs, cela se produit simplement, en fonction du code déclaratif que vous avez écrit.

Les documents React n'ont pas très bien expliqué cela, après les hooks, l'équipe principale de React et les créateurs de contenu n'ont pas fait de conférences ou de cours expliquant ces concepts.

La confusion conceptuelle de React

React semble avoir une « confusion conceptuelle », la transition vers les hooks en est l'exemple le plus fort, mais pas le seul. Il y a une grande différence dans l'utilisation des hooks, elle est basée sur la réactivité, et même si l'équipe principale de React plaisante sur la réactivité, c'était leur décision d'y passer.

Les composants fonctionnels sont parfaits pour cela. Chaque nouveau rendu appelle à nouveau la fonction, et tout ce qui se trouve à l'intérieur obtient la version actuelle de l'état et des accessoires, donc tout ce qui est créé à l'intérieur se comporte comme une dérivation. Le retour, le JSX, est la dérivation de l'UI.

Mais React n'est pas l'implémentation parfaite et pure de la programmation fonctionnelle et de la réactivité. Il s'inspire de concepts et d'idées et les fusionne pour créer son propre modèle, mais le noyau est là, de toute façon.

Et cela doit être clair. Même sans être l'exemple de la réactivité, il utilise leurs concepts, et connaître plus profondément les modèles permet à un développeur de réfléchir et de créer facilement des solutions avec ces primitives. C'est d'ailleurs pourquoi j'écris cette série « Réactivité dans React ».

Ne vous contentez pas de dire aux utilisateurs : "ne synchronisez pas l'état sur useEffect, c'est mauvais", mais expliquez pourquoi c'est mauvais et comment penser de manière à ce que "l'état de synchronisation" soit même la première solution envisagée.

Manque de quelques primitives

Cette cause s'améliore, en particulier dans React 19. Les dérivations asynchrones étaient l'une des causes de l'utilisation de useEffect, mais nous devrons maintenant utiliser primitive, ce qui comble cette lacune à certains égards.

Bien sûr, nous avons encore quelques points faibles dans les primitives, comme le cas des dérivations dynamiques, et d'autres cas, mais de plus en plus React déplace davantage les effets secondaires hors du champ des hooks, comme ce cas des rappels de référence.

Et on peut toujours espérer des nouvelles dans le futur. J'invite tout le monde à lire tous les autres articles sur la réactivité dans React et à apporter des cas et des questions spécifiques, nous pouvons explorer et trouver plus de solutions à ces problèmes courants de réactivité.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!