Comment construire un kit d'interface utilisateur React évolutif

Photo de Blake Wheeler

Chez Travix, nous avons un seul produit avec 4 thèmes différents. Chaque thème est une marque indépendante et chaque marque possède des sites Web. À l'heure actuelle, plus de 45 sites Web fonctionnent sur notre plateforme.

Deux de nos 4 marques différentes

Pour que tout fonctionne correctement, quelque 40 développeurs frontaux travaillent sur le produit et il est assez difficile de maintenir la cohérence de la base de code et de la conception.

Si vous travaillez dans un grand projet React, vous avez probablement une sorte de kit d'interface utilisateur intégré à votre base de code. Le composant Common Button, une implémentation générique Modal, un calendrier que vous utilisez tout le temps, des composants communs ne contenant aucune logique métier.

L'objectif principal de cet article est de vous aider à développer et à organiser votre kit d'interface utilisateur afin d'améliorer votre processus de développement et la cohérence de la conception de votre projet.

Comme vous pouvez l’imaginer, cette bibliothèque ne dépendra pas uniquement de votre équipe de développement. Vous devez également impliquer les concepteurs. Peu importe vos compétences ou les technologies que vous choisissez si votre équipe de conception vous demande 9 boutons différents et 22 tailles de police.

Si vous avez de la chance, ce ne sera pas un gros problème. Il est de plus en plus courant que les équipes de conception disposent d’un guide de style. Mais si la chance n'est pas votre meilleur atout, vous pouvez avoir quelque chose comme grayCantBeLighterThanThis nom de variable dans votre thème (histoire vraie).

La technologie

Comme le titre le dit, nous utilisons React pour construire notre application. La plupart des astuces de cet article peuvent facilement être utilisées dans différentes architectures, car elles possèdent des outils et des bibliothèques similaires.

Livre de contes

Storybook sera votre terrain de développement et votre galerie de composants. Il est utile de penser à votre composant comme un package isolé et de le dissocier de votre produit afin que vous puissiez avoir des propriétés génériques et bien décrites.

Composant non réutilisable

Une implémentation spécifique d'un bouton

Composant générique

Implémentation générique d'un bouton

Storybook est également un excellent moyen de fournir de la documentation. Il existe un module appelé storybook-addon-info qui ajoute automatiquement le composant JSX du composant et la description des types de propriétés à la page du composant.

L'exécution de toute votre application nécessite probablement quelques étapes et peut être très lente. Le livre de contes est généralement plus rapide à démarrer, il améliore donc votre vitesse de développement. Vous pouvez développer vos composants d'interface utilisateur en vous moquant de toutes les propriétés (les boutons de storybook-addon sont parfaits pour vous moquer) dans un terrain de jeu complètement isolé sans exécuter votre application principale.

Composants stylés

Vous aurez également besoin de quelque chose à traiter avec la thématisation. Nous avons déjà essayé des variables CSS pures et cela a bien fonctionné. Votre bundle aura deux fichiers CSS, un avec le composant de bibliothèque et un autre pour la déclaration de variables. Si vous avez plus d'un thème, il vous suffit de changer le fichier de thème et cela devrait fonctionner.

Theming utilisant du CSS pur

Dans notre nouvelle bibliothèque, nous avons opté pour Styled Components. Il fournit déjà une solution de thématisation et CSS dans JS fonctionne plutôt bien avec React. Vous avez également défini CSS par défaut, ce qui résout le plus gros problème d’informatique, le nommage.

C'est un excellent moyen d'éviter tout remplacement CSS inattendu et empêche également les développeurs de remplacer intentionnellement les règles CSS. Votre comportement de composant est associé à sa propre définition de propriétés et personne ne peut globalement remplacer les styles.

Cela vous aide également à mieux définir les règles conditionnelles dans vos styles, car vous n'avez pas besoin d'étendre les classes CSS ni de les gérer dans votre élément. En gros, vous transmettez des accessoires à un composant de vue et ce composant peut l’utiliser pour traiter les cas extrêmes.

Thème sélectionné disponible pour être utilisé dans nos composants

Chez Travix, nous avons créé un module Storybook pour changer facilement de thème. Si vous avez joué avec Styled Components ThemeProvider, vous savez que nous devons fondamentalement changer la propriété theme et que cela fonctionne comme un charme. Cet addon nous permet de tester toutes les marques lors du développement et aide également les propriétaires de produits et les concepteurs à valider la mise en œuvre.

Addon de sélecteur de thème

Manuscrit

Nous avons eu peu de problèmes pour implémenter TypeScript. Nous avons passé au moins deux semaines à mettre à jour notre solution pour la prendre en charge et plus de deux semaines à tout migrer. Si vous décidez de l'utiliser, je vous recommande vivement de démarrer votre projet avec TypeScript à partir de zéro.

Mais cela porte certainement ses fruits et l'auto-complétion des propriétés et des valeurs aide beaucoup lors du développement. Il vous aide également à définir de meilleurs contrats pour votre composant, car toute définition de type de propriété exotique allume un feu rouge pendant le processus de révision.

TypeScript autocomplete

Eslint

Pour assurer la cohérence de la base de code, nous avons une configuration Eslint super stricte. Nous avons décidé d’exercer des règles très strictes afin de ne pas perdre de temps à examiner les détails mineurs du code.

Notre linter s'exécute automatiquement avant toute transmission avec correction automatique modifiée au dernier commit. Il fonctionne également sur notre ordinateur CI. Ainsi, si quelqu'un décide de passer la validation, il échouera pendant la construction.

Processus de développement

La partie la plus importante pour nous ne concernait pas la technologie elle-même, mais le processus. Nous avons passé beaucoup de temps à essayer de la maintenir aussi stricte que possible afin de pouvoir garantir la qualité de la bibliothèque à long terme. Ceci est très important dans une grande entreprise car les développeurs partent, les développeurs rejoignent, mais votre base de code résistera à l'épreuve du temps.

Demande de tirage RFC

RFC signifie «demande de commentaires». Dans cette requête pull, nous n’implémentons pas une seule ligne de code. Nous ajoutons essentiellement un fichier de démarques décrivant notre composant. Cas d'utilisation, propriétés, rappels, effets secondaires possibles.

Votre nouvelle bibliothèque sera utilisée par toute la société et aura beaucoup de cas à traiter et de détails mineurs à régler. Les demandes d'extraction peuvent facilement devenir d'énormes discussions pour déterminer si le composant doit être un objet HOC ou renderProps, quelque chose de plus composable ou plus strict, contrôlé ou non contrôlé, etc. Donc, RFC vous aide à ne pas perdre de temps à mettre en œuvre quelque chose qui sera complètement changé après la révision.

Examen à la demande

Notre examen de demande d'extraction nécessite quelques étapes automatisées, trois approbations de développeur et les examens de bon de commande / concepteurs. Rien n'est fusionné si l'une de ces étapes échoue.

Etapes CI:
- Exécutez eslint et tests.
- Vérifiez si la couverture de code ne diminue pas.
- Générez un environnement de livre de récits unique (il met également à jour l'environnement si vous validez quelque chose de nouveau).

Les développeurs qui examinent votre demande d'extraction doivent uniquement vérifier si la mise en œuvre correspond à la RFC déjà approuvée et si la conception est correcte.

Les concepteurs et les PO peuvent examiner votre mise en œuvre à l’aide de l’environnement de scénario créé par votre CI.

Lancement d'une nouvelle version

Pour contrôler notre cycle de publication, nous avons décidé d'utiliser la version sémantique. Il ne reste donc qu'à ajouter «patch», «mineur» ou «majeur» dans notre message de validation de fusion. Une nouvelle version sera automatiquement publiée dans notre NPM privé. Notre CI met également à jour notre environnement de livre de contes principal.

Conclusion

Construire un kit d'interface utilisateur n'est pas une tâche facile et nécessitera beaucoup d'efforts de la part de votre équipe, mais cela vous aidera certainement à faire évoluer votre application et à la maintenir cohérente.

Toute mise à jour majeure de l’UI est facile à réaliser puisque nous gardons nos composants d’interface utilisateur isolés et qu’il est également assez facile d’ajouter une nouvelle marque. Il suffit d’ajouter un nouveau fichier de thème.

Le fait de déplacer notre déclaration de thème dans une bibliothèque externe présente un autre avantage: notre application principale ne s’intéresse pas du tout à la thématisation. C'est apatride dans ce sens parce que notre bibliothèque d'interface utilisateur prend soin de tous nos thèmes.

Et si vous avez une équipe de concepteurs qui codent (également appelés Licornes), ils peuvent commencer à prototyper en utilisant cette bibliothèque. Est-ce le prototype le plus fidèle ou non?

Si vous voulez utiliser quelque chose de similaire à ce que nous utilisons chez Travix, je vais extraire une partie de la base de code et créer un petit standard avec des composants stylés, TypeScript et Jest. C'était assez ennuyant de tout configurer, alors j'espère que ça vous plaira: https://github.com/leandrooriente/react-ui-kit-boilerplate.

Merci d'avoir lu.