Il y a plus de 4 ans, je suis tombé amoureux de
ReactJS et depuis lors, je développe toutes les applications Front End avec ce merveilleux outil. Pendant ce temps, moi et les équipes dans lesquelles j'ai eu la chance de travailler ont fait un tas d'erreurs, dont beaucoup ont été corrigées avec succès. De nombreuses solutions optimales ont été trouvées dans des expériences difficiles et coûteuses.
Aujourd'hui, je veux partager les erreurs les plus critiques et les plus douloureuses qui sont commises plus souvent que d'autres. Avant d'écrire cet article, j'ai bien sûr étudié Internet à la recherche d'articles similaires, et j'ai été surpris de constater que la plupart d'entre eux sont obsolètes et parlent de choses peu pertinentes en 2019. J'ai donc essayé de compiler une liste des problèmes les plus urgents en ce moment.
1. Les composants avec état (classes) sont pires que les crochets
Peut-être que cela vaut la peine de commencer avec la fonctionnalité
ReactJS la plus sensationnelle, qui est apparue dans la version 16.8+ Contrairement à certaines croyances, cette fonctionnalité était en proie à des erreurs de générations de développeurs précédentes et résout de nombreux problèmes. Si vous utilisez toujours des composants de classe au lieu de crochets en 2019, vous faites une grosse erreur et ne comprenez tout simplement pas quel est leur avantage. Je ne vais pas expliquer cela en détail dans cet article, regardez mieux
cette merveilleuse vidéo de Den Abramov , mais je ne pourrais tout simplement pas commencer cet article autrement
Bien sûr, ce n'est pas une erreur en soi, mais l'approche des classes par rapport aux hooks est beaucoup plus sujette aux erreurs, car de nombreux articles ont déjà été écrits sur:
- Les erreurs les plus courantes dans votre code React que vous faites (éventuellement)
- Les 7 erreurs les plus courantes qui font réagir les développeurs
2. Utilisation de fonctions anonymes comme accessoires
Si la première erreur peut encore être perçue comme un hommage à la mode, alors connaître la seconde, je vous l'assure, vous évitera des nuits blanches et des maux de tête. Après tout, c'est elle qui fait fonctionner l'application de manière si inadéquate que ses utilisateurs peuvent à jamais être déçus par
ReactJS . Mais nous voulons que les utilisateurs l'aiment, tout comme vous et moi, non? Pour éviter cette erreur, vous pouvez utiliser une règle très simple: ne passez JAMAIS une fonction anonyme au composant comme accessoire.
export default function MyOtherComponent() { return ( <MyComponent getValue={i => i.value} /> {/* */} ); }
Une version plus sophistiquée de cette erreur peut ressembler à ceci (ne lisez pas si vous n'êtes pas familier avec Redux):
import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; const mergeProps = ( { projectId, ...restState }: any, { fetchProjectData, ...restDispatch }: any, { memberId, ...restOwn }: any ) => ({ ...restState, ...restDispatch, ...restOwn, fetchProjectData: () => fetchProjectData(projectId), }); export default connect( mapStateToProps, mapDispatchToProps, mergeProps )(MyComponent);
Dans les deux cas, bien sûr, une fonction anonyme entre dans le composant
props . C'est mauvais car à chaque rendu de l'élément parent, cette fonction fera référence à un nouvel objet en mémoire, ce qui signifie qu'il ne sera pas égal au précédent et que votre composant sera correctement restitué inutilement. Cela peut ralentir les performances de votre application à tel point que vous allez vous-même commencer à cracher et à être déçu par
React , mais l'essentiel est dans les FONCTIONS ANONYMES dans les
accessoires . Ne le faites jamais - et soyez heureux.
Le problème est que, souvent, une telle erreur ne fait rien de mal. Le code fonctionne juste pour lui-même - et c'est tout. Et rien de notablement mauvais ne se produit. Exactement jusqu'au moment où vous appuyez à nouveau sur l'appel anonyme pour y recevoir des données du serveur (deuxième exemple), vous comprendrez alors la gravité du problème. L'accumulation de tels accessoires anonymes, par conséquent, ralentira votre demande au niveau d'expérience en 1995, lorsque nous avons dû demander aux voisins de libérer la ligne téléphonique pour télécharger la page.
Juste quelques mots, comment écrire correctement. Voici comment:
const getValue = i => i.value; return default function MyOtherComponent() { return ( <MyComponent getValue={getValue} /> ); }
import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; export default connect( mapStateToProps, mapDispatchToProps )(MyComponent);
3. Plusieurs instances de React dans l'application
Cette erreur concerne très probablement l'architecture de l'ensemble de l'application dans son ensemble, et pas seulement ReactJS en particulier. Mais ce problème pratique est souvent trop cher pour les développeurs et trop souvent pour les nuits blanches.
N'essayez pas de créer plus d'une instance de l'application React sur une seule page. En fait, dans la documentation React il n'y a pas d'interdiction de cette approche, j'ai même rencontré des recommandations pour faire juste cela dans certains articles (et, bien sûr, je l'ai fait dans mes applications), MAIS optimisation de cette approche et coordination de toutes les parties de l'application, dans ce cas commence à occuper plus de la moitié du temps de travail. Cela peut facilement être évité: par exemple, si vous devez répondre à certains événements dans le code hérité de votre nouvelle application
React , vous pouvez utiliser le modèle d'événement. Par exemple, comme ceci:
import React, { useCallback, useEffect } from 'react'; export default function MyComponent() { const reactHandlerOfLegacyEvent = useCallback((event) => {}, []); useEffect(() => { document.addEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); return () => { document.removeEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); }; }, [reactHandlerOfLegacyEvent]); return ({}); }
4. Écrire vos propres bibliothèques, au lieu des sources ouvertes existantes
Ce problème ne concerne pas du tout
ReactJS , mais l'ensemble du développement. Bien sûr, pendant que vous apprenez, l'écriture d'un grand nombre de vos propres bibliothèques vous permettra de croître plus rapidement et de devenir plus gros, mais si vous voulez être à la pointe de la programmation, il vous suffit d'essayer au moins chacune des bibliothèques open source qui résolvent vos problèmes. Demandez simplement aux robots de recherche s'il existe des bibliothèques qui résolvent votre problème - ils peuvent répondre parfaitement à ces questions.
Je ne donnerai pas d'exemple de bibliothèques que j'utilise moi-même, car Je sais que la moitié d'entre eux deviendront obsolètes dans quelques mois et que d'autres viendront à leur place. Et, semble-t-il, cela contredit la déclaration originale. Et vraiment, pourquoi utiliser des bibliothèques qui deviennent obsolètes en quelques mois? La réponse est très simple - vous pouvez voir la solution à ces problèmes qui ne se sont pas encore posés devant vous. Vous pouvez améliorer les pratiques existantes ou comprendre comment mieux résoudre le problème par l'exemple des problèmes dans les bibliothèques existantes. Cela ne peut se faire qu'en interagissant avec le monde du développement grâce à l'utilisation de bibliothèques open source.
5. Peur d'utiliser le code de quelqu'un d'autre
Comme l'erreur précédente, ce n'est pas
unique aux applications
ReactJS , mais c'est assez courant dans celles-ci. Combien de fois est-ce que je vois comment un grand mois de juin entre bravement dans la bataille et réécrit des parties du code qui fonctionnent très bien et qui n'ont aucun problème, juste parce qu'ils ont lu une des 4 erreurs précédentes. J'étais moi-même comme ça. Mais qu'y a-t-il à tricher, je perds souvent du temps maintenant, simplement parce que le mouvement est la vie.
Mais j'ai aussi appris à comprendre les autres développeurs, leurs pensées et les problèmes qu'ils ont rencontrés. Voir le temps et les efforts consacrés (et pas en vain) à résoudre des problèmes. Dans 3 cas sur 5, lorsque j'essaie «d'améliorer» le code de quelqu'un d'autre, j'obtiens presque le même résultat que moi. Tout simplement parce qu'au début d'une tâche, vous ne voyez généralement pas tous les problèmes à venir. Donc, maintenant je respecte le code de quelqu'un d'autre, même s'il me semble étrange et «dépassé». Ce que je vous conseille.
Je vous remercie
Merci d'avoir lu cet article et tous ceux avec qui j'ai la chance de travailler ensemble. Merci à nous d'avoir rendu notre monde plus intéressant et l'avoir fait avancer. Laissez pas toujours raison, pas toujours habilement, mais bougez.
Écrivez sur les problèmes que vous avez rencontrés dans les commentaires. Vous avez peut-être des solutions aux problèmes décrits dans cet article que j'ai ratés (je suis sûr que oui). Succès et bonne humeur!