À ne pas faire : renvoie de nouveaux tableaux ou de nouveaux objets depuis mapStateToProps. Si un objet doit être restitué, assurez-vous qu'il ne sera pas modifié ultérieurement. Cela pourrait conduire à un nouveau rendu du composant entier et du sous-arbre lorsque cet objet change, même le moins du monde. 

Do : mapstateToProps ne doit renvoyer que les primitives et les tableaux provenant directement de l'état (ne créez pas de nouveau tableau à partir de mapStateToProps, si nécessaire, créez un sélecteur qui met en cache le tableau résultant du calcul des arguments). Les tableaux qui seront itérés ultérieurement doivent contenir l'identifiant de chaîne de l'élément à restituer. L'élément de liste est chargé de trouver les informations sur l'état global en utilisant l'identifiant transmis par les accessoires.

Do : lorsque vous créez votre propre hook personnalisé, assurez-vous que le tableau à renvoyer est également mémorisé. L'optimisation prématurée n'est pas approuvée, mais pourquoi ne pas créer quelque chose de la manière la plus optimale possible, cela ne demande pas beaucoup d'efforts et favorise l'apprentissage des autres ingénieurs travaillant sur le code. Améliorez les compétences de l'équipe !

Do : lors de la construction d'un objet volumineux, classez les clés par ordre alphabétique. Les objets sont susceptibles de grossir et la recherche d’une propriété peut prendre beaucoup de temps. Surtout au magasin, assurez-vous que les réducteurs sont classés par ordre alphabétique.

À ne pas faire : créez des réducteurs spécifiques à la page/à l'écran que vous créez. Pensez à la manière dont cela pourrait s'adapter à d'autres pages/écrans. Consultez l'équipe pour voir les utilisations futures possibles des pages/écrans que vous créez.

Do : assurez-vous d'envelopper les communications avec des API externes avec une API personnalisée. À l’avenir, si le service doit être remplacé, cela pourra être fait via cette API personnalisée. Pensez à Bugsnag par exemple. Enveloppez ce petit garçon dans une API personnalisée au cas où vous souhaiteriez utiliser Sentry sur toute la ligne.

Do : Sur la même note. Veuillez standardiser la façon dont les erreurs sont gérées sur le backend mais aussi sur le frontend. Chaque action dans l'application doit être enveloppée dans un bloc try/catch et le bloc catch envoie des rapports à l'outil de rapport de bogues. Votre application doit également envelopper l’intégralité de l’application avec une limite d’erreur. Je crois qu’il existe une bonne façon d’établir le bon modèle en place. Un modèle capable de détecter toutes les erreurs et de signaler des informations significatives.

Do : utilisez un outil qui renforce la qualité du code tel que Sonar, cela vous fera gagner beaucoup de temps lors de la révision du code simplement parce que quelqu'un a décidé d'utiliser if ... else au lieu de if ... return . Des petits détails qui font qu'un développeur est moins créatif et se contente de suivre ce que disent les normes sonar en matière de qualité de code. Une base de code qui suit même ces détails jusqu'aux dents est facile à coder dès le premier jour.

Conclusion

Voici toutes les opinions que j'ai pour le moment. Ayant une base de code qui applique des modèles, les gens peuvent intervenir et récupérer un morceau de code ailleurs dans la base de code, le coller, modifier un peu le libellé et le tour est joué, vous disposez d'une fonctionnalité qui répond aux normes de production de toutes les manières possibles. Il y a des opinions mais il existe vraiment une manière plus performante de faire les choses, du moins au moment de la rédaction. D'autres approches peuvent être proposées, mais la manière la plus performante d'écrire le code au moment de l'écriture est la seule façon d'écrire le code. Plus facile à dire qu'à faire jusqu'à ce que vous rencontriez le monstre des délais.