Deux leçons que j'ai apprises en faisant des composants React

Voici quelques leçons que j'ai apprises sur la façon de ne pas construire de composants React. Ce sont des choses que j'ai rencontrées au cours des deux derniers mois et j'ai pensé qu'elles pourraient vous intéresser si vous travaillez sur un système de conception, en particulier avec un tas de décisions techniques héritées et beaucoup de dette technologique sous le capot.

Leçon 1: Évitez autant les composants des enfants que vous le pouvez

Une chose à propos de travailler sur un grand système de conception avec beaucoup de composants est que le modèle suivant commence finalement à devenir très problématique:

 <card>
  <card.header> title </card.header>
  <card.body> <p> Ceci est un contenu </p>  card.body>
</card.body></card>

Les parties problématiques sont ces composants enfants, card.body et card.header. Cet exemple n'est pas terrible parce que les choses sont relativement simples - c'est lorsque les composants deviennent plus complexes que les choses peuvent devenir des fous. Par exemple, chaque composant enfant peut avoir toute une série d'accessoires complexes qui interfèrent avec les autres.

L'un de mes plus grands points de douleur est avec nos composantes de forme. Prenez ceci:

 <formulaire></formulaire>
  

Soumettre Annuler form>

Je simplifie considérablement les choses, bien sûr, mais chaque fois qu'un ingénieur veut placer deux boutons côte à côte, il importerait des formulaires.actions, même s'il n'y avait pas de formulaire sur la page. Cela signifiait que tout dans le composant de formulaire est importé et c'est finalement mauvais pour les performances. Il se trouve que ce soit également une mauvaise implémentation de conception du système.

Cela rend également les choses très difficiles lors de la documentation des composants, car vous devrez maintenant vous assurer que chacun de ces composants enfants est également documenté.

Donc, au lieu de faire de la forme. De cette façon, nous n'avons pas à importer la forme tout le temps et nous pouvons garder les composants basés sur la disposition séparés des autres.

J'ai appris ma leçon. À partir de maintenant, j'éviterai complètement les composants des enfants là où je peux.

Leçon 2: Assurez-vous que vos accessoires ne sont pas en conflit les uns avec les autres

Mandy Michael a écrit un excellent article sur la façon dont les accessoires peuvent se heurter et provoquer toutes sortes de conflits déroutants, comme cet exemple de dactylographie:

 Interface Props {
  Hidemedia ?: Boolean
  Mediseisedgetoedge ?: Boolean
  Mediafullheight ?: Boolean
  Videoinline ?: Boolean
}

Mandy écrit:

Le but de ces accessoires est de modifier la façon dont l'image ou la vidéo est rendue dans la carte ou si les médias sont rendus du tout. Le problème avec les définir séparément est que vous vous retrouvez avec un certain nombre de drapeaux qui basculent les caractéristiques des composants, dont beaucoup s'excluent mutuellement. Par exemple, vous ne pouvez pas avoir une image qui remplit les marges si elle est également cachée.

C'était certainement un problème pour beaucoup de composants que nous avons hérités dans les systèmes de conception de mon équipe. Il y avait un tas de composants où les accessoires booléens rendraient un composant se comporter de toutes sortes de manières étranges et inattendues. Nous avions même toutes sortes de bugs apparaissant dans notre composant de carte pendant le développement parce que les ingénieurs ne sauraient pas quels accessoires s'allumer et désactiver pour un effet donné!

Mandy propose la solution suivante:

 type mediaMode = 'Hidden' | 'EdgeToedge' | 'Fullheight'

Interface Props {
  MediaMode: «Hidden» | 'EdgeToedge' | 'Fullheight'
}

En bref: si nous combinons toutes ces options naissantes ensemble, nous avons une API beaucoup plus propre qui est facilement extensible et est moins susceptible de provoquer une confusion à l'avenir.

C'est ça! Je voulais juste faire une note rapide sur ces deux leçons. Voici ma question pour vous: qu'avez-vous appris en matière de fabrication de composants ou de travailler sur des systèmes de conception?

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!