Par souci de concision, les scopes du package n'ont pas été mentionnées. L'utilisation des scopes vous permet de créer un package portant le même nom qu'un package créé par un autre utilisateur ou une autre organisation sans qu'il n'y ait de conflit.
+
+
+Maintenant que nous avons préparé notre package, nous pouvons le publier sur npm pour la première fois !
+
+## Gestion des mises en production avec Auto
+
+Pour publier des mises en production sur npm, nous utiliserons un processus qui met également à jour un historique des versions (changelog) qui décrit les modifications, définit un numéro de version appropré, et crée un tag git qui lie ce numéro de version à un commit dans notre référentiel. Pour vous aider, nous utiliserons un outil open-source appelé [Auto](https://github.com/intuit/auto), conçu précisément dans ce but. Auto est un outil en ligne de commande que nous pouvons utiliser pour diverses tâches courantes liées à la gestion des mises en production. Vous pouvez en savoir plus sur Auto en consultant [leur site de documentation](https://intuit.github.io/auto/).
+
+#### Obtenir un token GitHub et npm
+
+Pour les prochaines étapes, Auto communiquera avec GitHub et npm. Pour que cela fonctionne correctement, nous avons besoin d'un token d'accès personnel.
+Vous pouvez en obtenir un sur [cette page](https://github.com/settings/tokens) pour GitHub. Le token aura besoin des deux scopes `repo` et `workflow`.
+
+Pour npm, vous pouvez créer un token via l'URL suivante : https://www.npmjs.com/settings/<your-username>/tokens.
+
+Vous aurez besoin d'un token avec les permissions « Lecture et Publication ».
+
+Ajoutons ce token à un fichier appelé `.env` dans notre projet :
+
+```TEXT:title=.env
+GH_TOKEN=
+💡 N'oubliez pas d'ajuster les commandes en conséquence si vous utilisez yarn pour publier votre package.
+
+
+Et utilisez Auto pour mettre en production sur GitHub :
+
+```shell:clipboard=false
+git push --follow-tags origin main
+yarn release
+```
+
+Super !
+Nous avons publié avec succès notre package sur npm et fait une première mise en production sur GitHub (avec un peu de chance !).
+
+
+
+
+
+
+
+💡 Bien que nous ayons modifié les notes de version initiales pour qu'elles aient un sens pour la première version, `auto` génère automatiquement les notes de version basées sur les messages de commit pour les prochaines versions.
+
+
+
+Maintenant, quand nous lançons `yarn release`, nous allons passer par toutes les étapes que nous avons exécutées ci-dessus (sauf l'utilisation de l'historique auto-généré) de manière automatisée. Toutes les modifications apportées à la branche par défaut seront publiées.
+
+Bravo ! Vous avez mis en place l'infrastructure nécessaire pour publier manuellement les versions de votre design system. Apprenez maintenant à les automatiser grâce à l'intégration continue.
+
+## Mettre en production automatiquement
+
+Nous utilisons GitHub Actions pour l'intégration continue. Mais avant de continuer, nous devons stocker de manière sécurisée les tokens GitHub et NPM de tout à l'heure afin que Actions puisse y accéder.
+
+#### Ajoutez vos tokens à GitHub Secrets
+
+GitHub Secrets nous permet de stocker des informations sensibles dans notre référentiel. Dans une fenêtre du navigateur, ouvrez votre référentiel GitHub.
+
+Cliquez sur l'onglet ⚙️ Settings (Paramètres), puis sur le menu déroulant `Secrets and variables` dans la barre latérale, suivi du lien `Actions`. L'écran suivant apparaît :
+
+
+
+Cliquez sur le bouton **New repository secret**. Utilisez `NPM_TOKEN` pour le nom et collez le token que vous avez obtenu de npm plus tôt dans ce chapitre.
+
+
+
+Lorsque vous ajoutez le secret npm à votre référentiel, vous pourrez y accéder en via `secrets.NPM_TOKEN`. Vous n'avez pas besoin de définir un autre secret pour votre token GitHub. Tous les utilisateurs de GitHub ont automatiquement un `secrets.GITHUB_TOKEN` associé à leur compte.
+
+#### Automatiser les mises en production avec GitHub Actions
+
+Chaque fois que nous mergeons une Pull Request (PR), nous voulons publier automatiquement le design system. Créez un nouveau fichier appelé `push.yml` dans le même dossier que nous avons utilisé plus tôt pour publier Storybook et ajoutez le code suivant :
+
+```yml:title=.github/workflows/push.yml
+# Name of our action
+name: Release
+
+# The event that will trigger the action
+on:
+ push:
+ branches: [main]
+
+# what the action will do
+jobs:
+ release:
+ runs-on: ubuntu-latest
+ if: "!contains(github.event.head_commit.message, 'ci skip') && !contains(github.event.head_commit.message, 'skip ci')"
+ steps:
+ - uses: actions/checkout@v2
+
+ - name: Prepare repository
+ run: git fetch --unshallow --tags
+ - name: Use Node.js 16.x
+ uses: actions/setup-node@v3
+ with:
+ node-version: 16
+ - name: Install dependencies
+ uses: bahmutov/npm-install@v1
+ - name: Create Release
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ #👇 npm token, see https://storybook.js.org/tutorials/design-systems-for-developers/react/en/distribute/ to obtain it
+ NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
+ run: |
+ yarn release
+```
+
+
+Des permissions supplémentaires peuvent être nécessaires pour permettre à GitHub Actions de récupérer le contenu du référentiel et de publier le package dans npm. Consultez la documentation de GitHub pour plus d'informations.
+
+
+Enregistrez et effectuez un commit de vos modifications vers le dépôt distant.
+
+Bravo ! Désormais, chaque fois que vous mergerez une Pull Request (PR) dans la branche par défaut, une nouvelle version sera automatiquement publiée, en incrémentant le numéro de version comme il se doit grâce aux labels que vous avez ajoutés.
+
+💡 Nous n'avons pas parcouru toutes les fonctionnalités et intégrations d'Auto qui pourraient être utiles pour les design system en devenir. Consultez la documentation ici.
+
+
+
+## Importer le design system dans une application
+
+Maintenant que notre design system est en ligne, l'installation de la dépendance et l'utilisation des composants de l'interface utilisateur sont simples.
+
+#### Obtenir l'application d'exemple
+
+Plus tôt dans ce tutoriel, nous nous sommes basés sur un ensemble d'outils frontend populaires qui inclut React et Emotion. Cela signifie que notre application d'exemple doit également utiliser React et Emotion pour tirer pleinement parti du design system.
+
+
+
+💡 Bien que d'autres outils tels que Svelte ou Web Components, permettent de partager des composants UI sans dépendre d'un framework spécifique, nous nous sommes concentrés sur les méthodes les plus couramment utilisées et les plus documentées afin de garantir une prise en main rapide de ce tutoriel.
+Soyez assurés que nous explorerons d'autres méthodes dans les prochaines mises à jour.
+
+
+
+L'application d'exemple utilise Storybook pour faciliter le [développement centré sur les composants](https://www.componentdriven.org/), une méthodologie de développement d'applications qui développe des interfaces utilisateur à partir de la base, en commençant par les composants et en terminant par les pages. Nous utiliserons deux Storybooks en parallèle pendant la démonstration : un pour notre application d'exemple et un pour notre design system.
+
+Exécutez les commandes suivantes dans votre ligne de commande pour configurer l'application d'exemple :
+
+```shell:clipboard=false
+# Clones the files locally
+npx degit chromaui/learnstorybook-design-system-example-app example-app
+
+cd example-app
+
+# Install the dependencies
+yarn install
+
+## Start Storybook
+yarn storybook
+```
+
+Vous devriez voir le Storybook se lancer avec les stories des composants simples utilisés par l'application :
+
+
+
+Intégrer le design system
+ +Nous avons publié le Storybook de notre design system. Ajoutons-le à notre application d'exemple. Nous pouvons le faire en mettant à jour le fichier `.storybook/main.js` de l'application d'exemple avec ce qui suit : + +```diff:title=.storybook/main.js +/** @type { import('@storybook/react-vite').StorybookConfig } */ +const config = { + stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|ts|tsx)'], + addons: [ + '@storybook/addon-links', + '@storybook/addon-essentials', + '@storybook/addon-interactions', + ], + framework: { + name: '@storybook/react-vite', + options: {}, + }, + docs: { + autodocs: 'tag', + }, ++ refs: { ++ "design-system": { ++ title: 'My design system', ++ //👇 The url provided by Chromatic when it was deployed ++ url: 'https://your-published-url.chromatic.com', ++ }, ++ }, +}; +export default config; +``` + + + +
+Ajouter le
+
+Vous pourrez désormais parcourir les composants du design system et la documentation tout en développant l'application d'exemple. La mise en place du design system pendant le développement de nouvelles fonctionnalités augmente la probabilité que les développeurs réutilisent les composants existants au lieu de perdre du temps à les réinventer.
+
+Nous avons tout ce dont nous avons besoin, il est temps d'ajouter notre design system et de commencer à l'utiliser. Exécutez la commande suivante dans votre terminal :
+
+```shell
+yarn add @your-npm-username/learnstorybook-design-system
+```
+
+Nous devrons utiliser les mêmes styles globaux définis dans le design system, et donc mettre à jour le fichier de configuration [`.storybook/preview.jsx`](https://storybook.js.org/docs/react/configure/overview#configure-story-rendering) et ajouter un [décorateur global](https://storybook.js.org/docs/react/writing-stories/decorators#global-decorators).
+
+````diff:title=.storybook/main.js
+```jsx:title=.storybook/preview.jsx
+import { Global } from '@emotion/react';
+
+// The styles imported from the design system.
+import { global as designSystemGlobal } from '@your-npm-username/learnstorybook-design-system';
+
+const { GlobalStyle } = designSystemGlobal;
+
+/** @type { import('@storybook/react').Preview } */
+const preview = {
+ /*
+ * Adds a global decorator to include the imported styles from the design system.
+ * More on Storybook decorators at:
+ * https://storybook.js.org/docs/react/writing-stories/decorators#global-decorators
+ */
+ decorators: [
+ (Story) => (
+ <>
+ refs qui pointe vers .storybook/main.js, nous permet de créer plusieurs Storybook en un. Cette fonction est utile lorsque l'on travaille sur de gros projets qui nécessitent plusieurs technologies différentes.
+💡 Au fur et à mesure que votre design system se développe, vous pouvez être confronté aux exigences spécifiques de votre organisation qui justifient l'utilisation d'outils personnalisés ou même la création de votre propre site statique à l'aide d'outils tels que Gatsby ou Next. Il est facile de porter markdown et MDX vers d'autres solutions.
+
+
+## Importer le design system dans d'autres applications
+
+Jusqu'à présent, nous nous sommes concentrés sur l'aspect interne. Tout d'abord, en créant des composants d'interface utilisateur durables. Ensuite, en les examinant, les testant et les documentant. Nous allons maintenant nous tourner vers l'extérieur pour examiner la manière dont les équipes utilisent les design system.
+
+Le chapitre 7 traite de la transformation du design system sous forme de paquet en vue de son utilisation dans d'autres applications. Apprenez à combiner npm, le gestionnaire de paquets JavaScript, avec Auto, un outil de gestion des versions qui permet de gagner du temps.
diff --git a/content/design-systems-for-developers/react/fr/introduction.md b/content/design-systems-for-developers/react/fr/introduction.md
new file mode 100644
index 000000000..dfc814a7c
--- /dev/null
+++ b/content/design-systems-for-developers/react/fr/introduction.md
@@ -0,0 +1,104 @@
+---
+title: 'Introduction aux design system'
+tocTitle: 'Introduction'
+description: "Un guide sur les derniers outils pour créer des design system prêts à l'emploi"
+---
+
+Ce guide a été créé pour les développeurs professionnels qui souhaitent apprendre à créer des design system. Un niveau intermédiaire en JavaScript, Git et en intégration continue est recommandé. Vous devriez également avoir quelques bases en matière de Storybook, comme par exemple savoir écrire une story et éditer des fichiers de configuration (Rendez-vous sur Introduction à Storybook pour apprendre les bases).
+
++ +Les design system connaissent une popularité fulgurante. Des poids lourds en matière de tech comme Airbnb aux petites startups, les entreprises de toutes tailles réutilisent des modèles d'interface utilisateur (User Interface ou UI) dans le but de faire des économies de temps et d'argent. Il y a cependant une grande différence entre les design system créés par la BBC, Airbnb, IBM ou Microsoft et les design system créés par la plupart des développeurs. + +Pourquoi les équipes en charge des design system utilisent ces outils et ces techniques en particulier ? Mon co-auteur Tom et moi (Dominic) avons recherché les caractéristiques des design system les plus réussis de la communauté Storybook afin d'identifier les meilleures pratiques. + +Ce guide en plusieurs étapes présente les outils automatisés et les flux de travail minutieux utilisés dans les design system à grande échelle. Nous passerons en revue l'assemblage d'un design system à partir de librairies de composants existantes, puis nous mettrons en place les services de base, les librairies et les flux de travail. + + + +## Pourquoi autant d'engouement autour des design system ? + +Soyons clairs : le concept d'interface utilisateur réutilisable n'est pas nouveau. Les guides de style, les kits d'interface utilisateur et les widgets à partager existent depuis des décennies. Aujourd'hui, les designers et développeurs s'orientent vers la construction de composants d'interface utilisateur (UI). Un composant d'interface utilisateur encapsule les propriétés visuelles et fonctionnelles d'éléments distincts de l'interface utilisateur. Pensez aux LEGO. + +Les interfaces utilisateurs modernes sont constituées de centaines de composants modulaires qui sont réorganisés pour offrir différentes expériences utilisateurs. + +Les design system contiennent des composants d'interface utilisateur réutilisables qui aident les équipes à créer des interfaces utilisateur complexes, durables et accessibles pour tous les projets. Étant donné que les designers et les développeurs contribuent aux composants de l'interface utilisateur, le design system sert de lien entre les métiers. Il est également la « source de vérité » pour les composants communs d'une organisation. + + + +Les designers parlent souvent de la création des design system au sein de leurs outils. Dans son entièreté, un design system englobe les images (Sketch, Figma, etc.), les principes généraux de conception, la structure de contribution, la gouvernance, etc. Il existe une multitude de guides destinés aux designers qui traitent ces sujets en profondeur, nous n'y reviendrons donc pas ici. + +Pour les développeurs, plusieurs choses sont certaines. Les design system de production doivent inclure les composants de l'interface utilisateur et l'infrastructure frontend qui les gère. Un design system comporte trois parties techniques dont nous parlerons dans ce guide : + +- 🏗 Des composants d'interface utilisateur réutilisables mis en commun +- 🎨 Des jetons de conception (design tokens): Variables spécifiques au style telles que les couleurs de la marque et les espacements +- 📕 Une documentation : Instructions d'utilisation, narration, bonnes pratiques et erreurs à éviter + +Les éléments sont compilés, versionnés et distribués aux applications qui les utilisent par l'intermédiaire d'un gestionnaire de packages. + +## Avez-vous besoin d'un design system ? + +Bien qu'il soit populaire, un design system n'est pas une solution miracle. Si vous travaillez au sein d'une équipe restreinte sur une seule application, un dossier de composants d'interface utilisateur sera amplement suffisant plutôt que la mise en place d'une infrastructure nécessaire à la création d'un design system. Pour les petits projets, le coût de la maintenance, de l'intégration et des outils dépasse largement les bénéfices en termes de productivité que vous pourriez observer. + +Les économies d'échelles avec un design system jouent en votre faveur lorsque vous partagez des composants UI entre plusieurs projets. Si vous vous retrouvez à dupliquer des composants UI dans différentes applications ou équipes, ce guide est fait pour vous. + +## Ce que nous construisons + +Storybook alimente les design system de la [BBC](https://www.bbc.co.uk/iplayer/storybook/index.html?path=/story/style-guide--colours), [Airbnb](https://github.com/airbnb/lunar), [IBM](https://www.carbondesignsystem.com/), [GitHub](https://primer.style/css/), et de centaines d'autres entreprises. Les recommandations formulées ici s'inspirent des meilleures pratiques et des outils des équipes les plus performantes. Pour ce faire, nous utiliserons les outils frontend suivants : + +#### Construire des composants + +- 📚 [Storybook](http://storybook.js.org) pour le développement des composants d'interface utilisateur et une documentation générée automatiquement +- ⚛️ [React](https://reactjs.org/) pour une UI déclarative centrée sur les composants (via create-react-app) +- 💅 [Emotion](https://emotion.sh/docs/introduction) pour un style centré sur les composants +- ✨ [Prettier](https://prettier.io/) pour le formatage automatique du code + +#### Maintenir le système + +- 🚥 [GitHub Actions](https://github.com/features/actions) pour l'intégration continue +- 📐 [ESLint](https://eslint.org/) pour le linting JavaScript +- ✅ [Chromatic](https://www.chromatic.com/?utm_source=storybook_websiteutm_medium=link&utm_campaign=storybook) pour détecter les bugs visuels dans les composants (par les mainteneurs de Storybook) +- 📦 [npm](https://npmjs.com) pour partager la librairie +- 🛠 [Auto](https://github.com/intuit/auto) pour la gestion des mises en production + +#### Les addons Storybook + +- ♿ [Accessibility](https://github.com/storybookjs/storybook/tree/master/addons/a11y) pour contrôler l'accessibilité pendant le développement +- 💥 [Actions](https://storybook.js.org/docs/react/essentials/actions) pour l'assurance qualité des interactions au clic et au toucher +- 🎛 [Contrôles](https://storybook.js.org/docs/react/essentials/controls) pour ajuster interactivement les propriétés afin d'expérimenter avec les composants +- 📕 [Docs](https://storybook.js.org/docs/react/writing-docs/introduction) pour la génération automatique de documentation à partir des stories +- 🔍 [Interactions](https://storybook.js.org/addons/@storybook/addon-interactions/) pour le débogage des interactions entre composants +- 🏎 [Test-runner](https://storybook.js.org/docs/react/writing-tests/test-runner) pour tester les composants de manière automatisée + + + +## Comprendre le flux de travail + +Les design system sont un investissement dans l'infrastructure frontend. En plus de montrer comment utiliser la technologie ci-dessus, ce guide se concentre également sur les flux de travail de base qui favorisent la prise en main et simplifient la maintenance. Dans la mesure du possible, les tâches manuelles seront automatisées. Vous trouverez ci-dessous les activités que nous rencontrerons. + +#### Construire des composants d'interface utilisateur isolés + +Chaque design system est composé de composants d'interface utilisateur. +Nous utiliserons Storybook comme une sorte d' « atelier » pour construire des composants UI isolés en dehors de nos applications finales. Ensuite, nous intégrerons des addons qui vous aideront à garantir la durabilité des composants (Actions, A11y, Controls, Interactions). + +#### Relecture pour parvenir à un consensus et recueillir les retours + +Le développement de l'interface utilisateur est un travail d'équipe qui nécessite un alignement entre les développeurs, les designers et les autres acteurs du projet. Nous publierons des composants d'interface utilisateur en cours de développement afin d'intégrer les parties prenantes au processus de développement et d'accélérer les livraisons. + +#### Tester pour éviter les bugs de l'interface utilisateur + +Les design system sont une source de vérité et un point unique de défaillance. Des bugs mineurs dans des composants de base peuvent provoquer des incidents à l'échelle de l'entreprise. Nous automatiserons les tests pour vous aider à atténuer les bugs inévitables et à livrer en toute confiance des composants d'interface utilisateur durables et accessibles. + +#### Documenter pour accélérer la prise en main + +La documentation est essentielle, mais sa création est souvent la dernière priorité d'un développeur. Nous vous faciliterons la tâche pour documenter les composants de l'interface utilisateur en générant automatiquement une documentation minimale et durable qui peut être personnalisée. + +#### Partager le design system aux projets qui l'utilisent + +Une fois vos composants d'interface utilisateur finalisés et bien documentés, vous devez les partager aux autres équipes. Nous aborderons le packaging, la publication et la manière d'utiliser le design system dans d'autres Storybook. + +## Le design system de Storybook + +L'exemple de design system de ce guide s'inspire du [design system officiel](https://github.com/storybookjs/design-system) de Storybook. Il est utilisé par trois sites et touche des dizaines de milliers de développeurs dans l'écosystème Storybook. + +Dans le chapitre suivant, nous vous montrerons comment extraire un design system à partir de librairies de composants hétérogènes. diff --git a/content/design-systems-for-developers/react/fr/review.md b/content/design-systems-for-developers/react/fr/review.md new file mode 100644 index 000000000..c2f000bd8 --- /dev/null +++ b/content/design-systems-for-developers/react/fr/review.md @@ -0,0 +1,209 @@ +--- +title: 'Relecture avec les équipes' +tocTitle: 'Relecture' +description: "Collaborer grâce à l'intégration continue et l'examen visuel" +commit: 'fe0944a' +--- + +Dans ce chapitre 4, nous en apprendrons plus sur les flux de travail professionnels pour apporter des améliorations au design system tout en atténuant les incohérences. Ce chapitre présente les techniques permettant de recueillir des retours sur l'interface utilisateur et de parvenir à un consensus avec votre équipe. +Ces processus de production sont utilisés par des personnes travaillant pour Auth0, Shopify et Discovery Network. + +## Source unique de vérité ou point de défaillance unique + +Précédemment, j'ai écrit que les design system sont un [point de défaillance unique](https://www.chromatic.com/blog/why-design-systems-are-a-single-point-of-failure) pour les équipes frontend. Par essence, les design system sont des dépendances. Si vous modifiez un composant du design system, cette modification se propage aux applications dépendantes. Le mécanisme de publication des modifications n'est pas biaisé : il renvoie à la fois les améliorations et les bugs. + + + +Les bugs constituent un risque existentiel pour les design system, c'est pourquoi nous ferons tout pour les éviter. Des ajustements mineurs finissent par avoir des impacts et peuvent entraîner d'innombrables régressions. En l'absence d'une stratégie de maintenance continue, les design system se détériorent. + +> « Mais ça marche sur mon ordinateur ?! » - tout le monde + +## Revue visuelle des composants UI avec votre équipe + +La revue visuelle est le processus qui valide le comportement et le rendu des interfaces. Elle a lieu à la fois pendant le développement de l'interface utilisateur et pendant l'étape d'assurance qualité avec l'équipe. + +La plupart des développeurs connaissent bien la revue du code, qui consiste à recueillir les commentaires d'autres développeurs sur le code afin d'en améliorer la qualité. Étant donné que les composants de l'interface utilisateur expriment le code de manière graphique, une revue visuelle est nécessaire pour recueillir les commentaires sur l'UI (Interface Utilisateur) et l'UX (Expérience Utilisateur). + +### Établir un point de référence universel + +Supprimer le contenu du répertoire node_modules. Réinstaller les packages. Effacer le stockage local. +Supprimer les cookies. Si ces actions vous semblent familières, vous savez à quel point il est difficile de s'assurer que les coéquipiers se réfèrent au code le plus récent. Lorsque les gens n'ont pas des environnements de développement identiques, c'est un cauchemar de discerner les problèmes causés par l'environnement local des bugs réels. + +Heureusement, en tant que développeurs frontend, nous avons une cible de compilation commune : le navigateur. Les équipes avisées publient leur Storybook en ligne pour servir de point de référence universel lors de la revue visuelle, évitant ainsi les complications inhérentes aux environnements de développement locaux (il est de toute façon ennuyeux d'être le support technique). + + + +Lorsque les composants existants de l'interface utilisateur sont accessibles via une URL, les utilisateurs peuvent confirmer l'aspect et la fonctionnalité de l'interface utilisateur simplement depuis leur navigateur. Cela signifie que les développeurs, les designers et les chefs de produit n'ont pas à se préoccuper d'un environnement de développement local, à faire circuler des captures d'écran ou à se référer à des interfaces utilisateur obsolètes. + +> « Déployer Storybook à chaque Pull Request (PR) rend la revue visuelle plus facile et aide les chefs de produits à penser en matière de composants ». - Norbert de Langen, mainteneur principal de Storybook + +
Publier le Storybook
+ +Nous ferons la démonstration d'un processus de revue visuelle avec [Chromatic](https://www.chromatic.com/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook), un service de publication gratuit créé par les mainteneurs de Storybook. Cela vous permet de déployer et d'héberger votre Storybook en toute sécurité dans le cloud, mais il est également assez simple de [développer Storybook comme un site statique et de le déployer](https://storybook.js.org/docs/react/sharing/publish-storybook) sur d'autres services d'hébergement. + +### Obtenir Chromatic + +Tout d'abord, allez sur [chromatic.com](https://www.chromatic.com/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook) et inscrivez-vous avec votre compte GitHub. + + + +A partir de là, sélectionnez le dépôt de votre design system. + +En arrière-plan, les autorisations d'accès seront synchronisées et les Pull Request (PR) vérifiées. + + + +Installez le package [chromatic](https://www.npmjs.com/package/chromatic) via npm. + +```shell +yarn add --dev chromatic +``` + +Une fois installé, lancez la commande suivante pour développer et déployer votre Storybook (vous devrez utiliser le `project-token` que Chromatic fournit sur le site web) : + +```shell +npx chromatic --project-token=Intégration continue
+ +L'intégration continue est la méthode la plus utilisée pour assurer la maintenance des applications web modernes. Elle vous permet d'effectuer des tests, des analyses et des déploiements à chaque fois que vous ajoutez du code. Nous adopterons cette technique pour nous épargner des actions manuelles et répétitives. + +Nous utiliserons GitHub Actions, qui est gratuit pour notre cas d'utilisation simple. Les mêmes principes s'appliquent aux autres services d'intégration continue. + +Ajoutez un dossier `.github` au plus au niveau de votre projet. Créez ensuite un autre dossier appelé `workflows`. + +Créez un fichier appelé chromatic.yml comme celui ci-dessous. Il nous permettra de scripter le comportement de notre processus d'intégration continue. Nous allons commencer avec quelque chose de simple pour l'instant et continuer à l'améliorer au fur et à mesure que nous avancerons : + +```yaml:title=.github/workflows/chromatic.yml +# Name of our action +name: 'Chromatic' +# The event that will trigger the action +on: push + +# What the action will do +jobs: + test: + # The operating system it will run on + runs-on: ubuntu-latest + # The list of steps that the action will go through + steps: + - uses: actions/checkout@v2 + with: + #👇 Fetches all history so Chromatic can compare against previous builds + fetch-depth: 0 + - uses: actions/setup-node@v3 + with: + #👇 Sets the version of Node.js to use + node-version: 16 + - run: yarn + #👇 Adds Chromatic as a step in the workflow + - uses: chromaui/action@v1 + # Options required for Chromatic's GitHub Action + with: + #👇 Chromatic projectToken, see https://storybook.js.org/tutorials/design-systems-for-developers/react/en/review/ to obtain it + projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }} + token: ${{ secrets.GITHUB_TOKEN }} +``` + +
+💡 Par souci de concision, les Github Secrets n'ont pas été mentionnés. Les secrets sont des variables d'environnement sécurisées fournies par GitHub afin que vous n'ayez pas à coder en dur le project-token.
💡 Chromatic propose également un flux de travail complet de revue de l'interface utilisateur intégré au produit avec son offre payante. La technique qui consiste à copier les liens Storybook dans une PR GitHub fonctionne à plus petite échelle (et avec n'importe quel service qui héberge votre Storybook, pas seulement Chromatic), mais au fur et à mesure que votre utilisation augmente, vous pouvez considérer ce service car il automatise le processus.
+
+
+Dans le domaine du développement de logiciels, la plupart des défauts sont dus à une mauvaise communication et non à la technologie. La revue visuelle permet aux équipes de recueillir un retour d'information continu pendant le développement afin de livrer plus rapidement les design system.
+
+
+
+> Déployer une URL Storybook pour chaque Pull Request est quelque chose que nous faisons depuis un certain temps dans le design system de Shopify, Polaris, et cela s'est avéré incroyablement utile. Ben Scott, Ingénieur chez Shopify
+
+## Tester votre design system
+
+La revue visuelle est inestimable. Cependant, relire et examiner des centaines de stories de composants peut prendre des heures. Idéalement, nous voulons voir uniquement les changements intentionnels (ajouts / améliorations) et détecter automatiquement les régressions non intentionnelles.
+
+Dans le chapitre 5, nous présentons les stratégies de tests qui allègent la revue visuelle et garantissent la durabilité de nos composants dans le temps.
diff --git a/content/design-systems-for-developers/react/fr/test.md b/content/design-systems-for-developers/react/fr/test.md
new file mode 100644
index 000000000..1ebf222be
--- /dev/null
+++ b/content/design-systems-for-developers/react/fr/test.md
@@ -0,0 +1,339 @@
+---
+title: 'Tester pour garantir la qualité'
+tocTitle: 'Tester'
+description: "Comment tester l'apparence, les fonctionnalités et l'accessibilité du design system"
+commit: 'f5a815f'
+---
+
+Dans ce chapitre 5, nous automatisons les tests du design system pour éviter les bugs de l'interface utilisateur. Ce chapitre explore en profondeur les caractéristiques des composants UI qui justifient des tests et les pièges potentiels à éviter. Nous avons observé les équipes professionnelles de chez Wave, BBC et Salesforce pour aboutir à une stratégie de test qui concilie une couverture complète, une configuration simple et une maintenance réduite.
+
+
+
+## Les fondamentaux des tests de composants UI
+
+Avant de commencer, déterminons ce qu'il est judicieux de tester. Les design system sont composés d'éléments d'interface utilisateur. Chaque composant UI comprend des stories (variations) qui décrivent l'apparence et la fonctionnalité souhaitées en fonction d'un ensemble de paramètres (propriétés). Les stories sont ensuite affichées par le navigateur ou l'appareil à l'utilisateur final.
+
+
+
+Wouah ! Comme vous pouvez le constater, un composant contient plusieurs états.
+Multipliez le nombre d'états par le nombre de composants du design system et vous comprendrez pourquoi il est difficile de les répertorier. En réalité, il n'est pas viable de tester chaque élément à la main, en particulier au fur et à mesure que le design system se développe. Une raison de plus de mettre en place des tests automatisés **dès maintenant** afin d'économiser du travail **à l'avenir**.
+
+## Préparer les tests
+
+J'ai interrogé 4 équipes équipes frontend sur les flux de travail professionnels de Storybook dans un [article précédent](https://www.chromatic.com/blog/the-delightful-storybook-workflow). Ils se sont mis d'accord sur ces bonnes pratiques pour rédiger des stories afin de rendre les tests faciles et complets.
+
+**Articuler les états des composants pris en charge** en tant que stories pour clarifier quelles combinaisons de paramètres produisent un état donné. Eliminer les états non utilisés pour alléger le composant.
+**Affichez les composants de manière cohérente** pour atténuer la variabilité qui peut être déclenchée par des fonctions aléatoires (Math.random()) ou relatives (Date.now()).
+
+> Les meilleures stories vous permettent de visualiser tous les états que votre composant pourrait connaître dans l'application » - Tim Hingston, Tech lead chez Apollo GraphQL
+
+## Tests visuels
+
+Les design system contiennent des composants d'interface utilisateur dédiés à de l'affichage, qui sont intrinsèquement visuels. Les tests visuels valident les aspects visuels de l'interface utilisateur affichée.
+
+Les tests visuels capturent une image de chaque composant de l'interface utilisateur dans un environnement de navigation cohérent. Les nouvelles captures d'écran sont automatiquement comparées aux captures d'écran de référence précédemment acceptées. Lorsqu'il y a des différences visuelles, vous en êtes informé.
+
+
+
+Si vous développez une interface utilisateur moderne, les tests visuels permettent à votre équipe frontend d'éviter les modifications manuelles fastidieuses et les régressions coûteuses de l'interface utilisateur.
+
+Dans le chapitre précédent, nous avons appris à publier un Storybook en utilisant [Chromatic](https://www.chromatic.com/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook). Nous avons ajouté une bordure rouge en gras autour de chaque composant `Button`, puis nous avons demandé l'avis de nos coéquipiers.
+
+
+
+Voyons maintenant comment fonctionnent les tests visuels à l'aide des [outils de test](https://www.chromatic.com/features/test/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook) intégrés de Chromatic. Lorsque nous avons créé la Pull Request (PR), Chromatic a capturé des images de nos modifications et les a comparées aux versions précédentes des mêmes composants. Quatre changements ont été trouvés :
+
+
+
+Cliquez sur la partie **🟡 UI Tests** pour les passer en revue.
+
+
+
+Passez-les en revue pour confirmer s'ils sont intentionnels (améliorations) ou non intentionnels (bugs). Si vous acceptez les modifications, les bases de référence des tests seront mises à jour. Cela signifie que les modifications ultérieures seront comparées aux nouvelles références afin de détecter les bugs.
+
+
+
+Dans le dernier chapitre, notre coéquipier ne voulait pas d'une bordure rouge autour des `Button` pour une raison ou une autre. Refusez les modifications pour indiquer qu'elles doivent être annulées.
+
+
+
+Annulez les changements et faites un commit pour relancer et valider vos tests visuels.
+
+## Tests d'interaction
+
+Jusqu'à présent, nous avons vu comment les tests visuels nous permettaient de vérifier l'apparence et de détecter les régressions de l'interface utilisateur. Mais au fur et à mesure que nous développons notre design system, nos composants deviendront responsables de bien plus que le simple rendu de l'interface utilisateur. À un moment donné, ils s'occuperont de la gestion de l'état ou même de la recherche de données. C'est là que les tests d'interaction entre les composants nous aideront.
+
+Le test d'interaction est un modèle bien connu pour vérifier le comportement de l'utilisateur. Vous commencez par fournir des données simulées pour mettre en place votre test, simuler les interactions de l'utilisateur avec une librairie de test et vérifier les modifications de l'interface utilisateur. Dans Storybook, cela se déroule dans le navigateur, ce qui facilite le débogage parce que vous exécutez les tests dans le même environnement que celui dans lequel vous développez les composants : le navigateur.
+
+Pour l'activer, nous allons cliquer sur la fonction [`play`](https://storybook.js.org/docs/react/writing-stories/play-function) de Storybook et sur les librairies de test instrumentées pour configurer nos tests, puis utiliser le [test-runner](https://storybook.js.org/docs/react/writing-tests/test-runner) pour vérifier que le rendu de notre composant est correct.
+
+### Configurer le test runner
+
+Commencez par ajouter les dépendances nécessaires avec :
+
+```shell
+yarn add --dev @storybook/test-runner
+```
+
+Ensuite, ajoutez une nouvelle tâche de test à vos scripts dans le `package.json` :
+
+```json:clipboard=false
+{
+ "scripts": {
+ "test-storybook": "test-storybook"
+ }
+}
+```
+
+### Ecrire un test d'interaction en utilisant la fonction play
+
+Les tests d'interaction sont centrés sur la façon dont l'interface utilisateur gère les actions de l'utilisateur, soit en utilisant le clavier, la souris ou d'autres périphériques d'entrée et en vérifiant si les éléments visuels de l'interface utilisateur sont affichés et fonctionnent correctement. Les libraires de test telles que [Jest](https://jestjs.io/) fournissent des API utiles pour simuler les interactions humaines et vérifier l'état de l'interface utilisateur. Nous utiliserons des versions instrumentées de ces outils pour écrire nos tests. Le but est donc de conserver une syntaxe commune, mais avec des données d'analyse supplémentaires pour nous aider à déboguer.
+
+Le test lui-même est défini dans une fonction [`play`](https://storybook.js.org/docs/react/writing-stories/play-function) reliée à une story. Il s'agit de petits bouts de code qui s'exécutent après le rendu de la story.
+
+Voyons comment cela fonctionne en mettant à jour la story `Button` et en mettant en place notre premier test d'interaction en ajoutant ce qui suit :
+
+```diff:title=src/Button/Button.stories.jsx
+import styled from '@emotion/styled';
+
+import { Button } from './Button';
+import { Icon } from '../Icon/Icon';
+import { StoryLinkWrapper } from '../LinkWrapper';
+
++ import { expect, userEvent, within } from '@storybook/test';
+
+export default {
+ title: 'Design System/Button',
+ component: Button,
+};
+
+// Other Button stories
+
+/*
+ * New story using the play function.
+ * See https://storybook.js.org/docs/react/writing-stories/play-function
+ * to learn more about the play function.
+ */
++ export const WithInteractions = {
++ args: {
++ appearance: 'primary',
++ href: 'http://storybook.js.org',
++ ButtonWrapper: StoryLinkWrapper,
++ children: 'Button',
++ },
++ play: async ({ canvasElement }) => {
++ // Assigns canvas to the component root element
++ const canvas = within(canvasElement);
++ await userEvent.click(canvas.getByRole('link'));
++ expect(canvas.getByRole('link')).toHaveAttribute(
++ 'href',
++ 'http://storybook.js.org',
++ );
++ },
++ };
+```
+
+
+
+💡 Le package `@storybook/test` remplace les packages de tests `@storybook/jest` et `@storybook/testing-library`, offrant une taille de package plus petite et une API plus directe basée sur le package [Vitest](https://vitest.dev/).
+
+
+
+
+
+Lorsque Storybook a fini d'afficher la story, il exécute les étapes définies à l'intérieur de la fonction `play`, en interagissant avec le composant, de la même manière qu'un utilisateur le ferait. Cliquez sur le panneau [`Interactions`](https://storybook.js.org/docs/react/writing-tests/interaction-testing#interactive-debugger). Vous verrez un flux d'exécution détaillé tout en disposant d'un ensemble pratique de contrôles d'interface utilisateur pour mettre en pause, reprendre, revenir en arrière et passer en revue chaque interaction.
+
+### Automatiser les tests avec le test runner
+
+Nous avons vu de quelle manière les tests d'interaction avec la fonction `play` nous ont aidé à vérifier comment un composant réagit lorsque nous interagissons avec lui. Mais avec l'évolution des design system, la vérification manuelle de chaque modification peut rapidement devenir irréaliste. Storybook test runner automatise ce processus. Il s'agit d'un utilitaire autonome alimenté par [Playwright](https://playwright.dev/), qui fonctionne en parallèle de votre Storybook, exécutant tous les tests d'interaction et détectant les stories cassées. Avec Storybook en cours d'exécution, ouvrez une nouvelle fenêtre dans votre terminal et exécutez le test runner avec :
+
+```shell
+yarn test-storybook --watch
+```
+
+
+
+Il vérifiera que toutes nos stories sont affichées sans erreur et que tous les cas passent automatiquement pendant l'exécution. De plus, si un test échoue, il nous fournira un lien qui ouvrira le composant concerné dans le navigateur.
+
+### Exécuter des tests d'interaction dans la CI (intégration continue)
+
+Les tests d'interaction avec la fonction `play` et l'automatisation avec le test runner nous ont aidé à simuler les interactions de l'utilisateur et à vérifier l'état de l'interface utilisateur de nos composants. Cependant, les exécuter localement peut être une tâche longue et répétitive, même si notre design system continue à se développer. Une fois de plus, c'est là que la CI intervient. Voyons comment la mettre en place dans notre flux de travail d'intégration continue existant. Mettez à jour le flux de travail existant que nous avons créé dans le [chapitre précédent](/design-systems-for-developers/react/fr/review/#chromatic-ci) et activez les tests d'interaction comme suit :
+
+```yaml:title=.github/workflows/chromatic.yml
+# Name of our action
+name: 'Chromatic'
+# The event that will trigger the action
+on: push
+
+# What the action will do
+jobs:
+ # Run interaction tests
+ interaction-tests:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v2
+ - uses: actions/setup-node@v3
+ with:
+ #👇 Sets the version of Node.js to use
+ node-version: 16
+ - name: Install dependencies
+ run: yarn
+ - name: Install Playwright
+ run: npx playwright install --with-deps
+ - name: Build Storybook
+ run: yarn build-storybook --quiet
+ - name: Serve Storybook and run tests
+ run: |
+ npx concurrently -k -s first -n "SB,TEST" -c "magenta,blue" \
+ "npx http-server storybook-static --port 6006 --silent" \
+ "npx wait-on tcp:6006 && yarn test-storybook"
+ visual-tests:
+ # The operating system it will run on
+ runs-on: ubuntu-latest
+ # The list of steps that the action will go through
+ steps:
+ - uses: actions/checkout@v2
+ with:
+ #👇 Fetches all history so Chromatic can compare against previous builds
+ fetch-depth: 0
+ - uses: actions/setup-node@v3
+ with:
+ #👇 Sets the version of Node.js to use
+ node-version: 16
+ - run: yarn
+ #👇 Adds Chromatic as a step in the workflow
+ - uses: chromaui/action@v1
+ # Options required for Chromatic's GitHub Action
+ with:
+ #👇 Chromatic projectToken, see https://storybook.js.org/tutorials/design-systems-for-developers/react/en/review/ to obtain it
+ projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
+ token: ${{ secrets.GITHUB_TOKEN }}
+```
+
+Notre flux de travail s'exécutera lorsque le code sera ajouté sur n'importe quelle branche du dépôt de notre design system, et il aura deux tâches : une pour les tests d'interaction et une pour les tests visuels. La tâche de test d'interaction commence par le build du Storybook et exécute ensuite le programme de test, en nous informant des tests qui ne fonctionnent pas. La tâche de test visuel fonctionnera comme auparavant, en exécutant Chromatic pour vérifier l'état visuel de nos composants.
+
+## Test d'accessibilité
+
+« L'accessibilité signifie que toutes les personnes, y compris les personnes en situation de handicap, peuvent comprendre, naviguer et interagir avec votre application ... En ligne, [des exemples présentent] des moyens alternatifs d'accéder au contenu, comme l'utilisation de la touche de tabulation et d'un lecteur d'écran pour parcourir un site », écrit le développeur [Alex Wilson de T.Rowe Price](https://medium.com/storybookjs/instant-accessibility-qa-linting-in-storybook-4a474b0f5347).
+
+Les handicaps touchent 15 % de la population, selon [l'Organisation mondiale de la santé](https://www.who.int/disabilities/world_report/2011/report/en/). Les design system ont un impact considérable sur l'accessibilité car ils contiennent les éléments constitutifs des interfaces utilisateur. L'amélioration de l'accessibilité d'un seul composant signifie que toutes les instances de ce composant dans votre entreprise en bénéficient.
+
+
+
+Prenez une longueur d'avance en matière d'interface utilisateur inclusive grâce à l'addon Accessibility de Storybook, un outil en temps réel permettant de vérifier les normes d'accessibilité du Web (WCAG).
+
+```shell
+yarn add --dev @storybook/addon-a11y
+```
+
+Mettez à jour votre configuration Storybook pour inclure l'addon.
+
+```diff:title=.storybook/main.js
+/** @type { import('@storybook/react-vite').StorybookConfig } */
+const config = {
+ stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|ts|tsx)'],
+ addons: [
+ '@storybook/addon-links',
+ '@storybook/addon-essentials',
+ '@storybook/addon-interactions',
++ '@storybook/addon-a11y',
+ ],
+ framework: {
+ name: '@storybook/react-vite',
+ options: {},
+ },
+ docs: {
+ autodocs: 'tag',
+ },
+};
+export default config;
+
+```
+
+Une fois que tout est configuré, vous verrez un nouvel onglet « Accessibilité » dans le panneau des addons de Storybook.
+
+
+
+Il vous montre les niveaux d'accessibilité des éléments DOM (violations et validations). Cliquez sur la case à cocher « mettre en évidence les résultats » pour visualiser les violations directement dans le composant UI.
+
+
+
+À partir de là, suivez les recommandations de l'addon en matière d'accessibilité.
+
+## Autres stratégies de test
+
+Paradoxalement, les tests peuvent faire gagner du temps mais aussi ralentir la vitesse de développement en raison de la maintenance. Faites preuve de discernement en testant les bons éléments uniquement. Bien que le développement de logiciels comporte de nombreuses stratégies de test, nous avons découvert à nos dépens que certaines d'entre elles ne sont pas adaptées aux design system.
+
+### Tests de couverture du code
+
+Les tests de couverture du code mesurent la part de votre base de code couverte par les tests. C'est un bon moyen de s'assurer que vos tests testent réellement quelque chose. Cependant, ils ne constituent pas un bon moyen de mesurer la qualité de vos tests, mais ils peuvent être utiles pour vérifier que tous les composants et utilitaires fournis par le design system fonctionnent comme prévu, ce qui permet d'identifier toute lacune ou tout problème potentiel dans la mise en œuvre du design system. Storybook fournit un [addon](https://storybook.js.org/addons/@storybook/addon-coverage/) pour nous aider dans cette tâche. Développé par [Istanbul](https://istanbul.js.org/), l'addon coverage de Storybook génère un rapport de couverture de code pour vos stories Storybook. Voyons comment.
+
+Commencez par lancer la commande suivante pour installer l'addon coverage :
+
+```shell
+yarn add --dev @storybook/addon-coverage
+```
+
+Ensuite, mettez à jour votre configuration Storybook pour inclure l'addon :
+
+```diff:title=.storybook/main.js
+/** @type { import('@storybook/react-vite').StorybookConfig } */
+const config = {
+ stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|ts|tsx)'],
+ addons: [
+ '@storybook/addon-links',
+ '@storybook/addon-essentials',
+ '@storybook/addon-interactions',
+ '@storybook/addon-a11y',
++ '@storybook/addon-coverage',
+ ],
+ framework: {
+ name: '@storybook/react-vite',
+ options: {},
+ },
+ docs: {
+ autodocs: 'tag',
+ },
+};
+export default config;
+```
+
+Enfin, un fois que Storybook est affiché, lancer le test runner (dans une nouvelle fenêtre du terminal) avec le flag `--coverage` :
+
+```shell
+yarn test-storybook --coverage
+```
+
+
+
+A partir d'ici, suivez les recommandations pour améliorer votre couverture de code.
+
+#### Tests instantanés (Jest)
+
+Cette technique permet de capturer le code des composants de l'interface utilisateur et de le comparer aux versions précédentes. Tester le balisage des composants de l'interface utilisateur revient à tester les détails de l'implémentation (code), et non l'expérience de l'utilisateur dans le navigateur.
+
+Les tests instantanés (snapshots) sont imprévisibles et sujets à des faux positifs. Au niveau des composants, le test instantané ne tient pas compte des changements globaux tels que les design tokens, les feuilles de style CSS et les mises à jour d'API tierces (polices web, formulaires Stripe, Google Maps, etc.). Dans la pratique, les développeurs ont recours à l'«approbation totale» ou ignorent complètement les tests instantanés.
+
+> La plupart des tests d'instantanés de composants ne sont en fait qu'une version aggravée des tests d'instantanés d'écran. Testez l'affichage. Testez ce qui est affiché, et non le balisage sous-jacent (inutile !). - Mark Dalgliesh, infrastructure Frontend chez SEEK, créateur de modules CSS
+
+#### Tests end-to-end (Selenium, Cypress)
+
+Les tests end-to-end traversent le DOM du composant pour simuler le parcours de l'utilisateur. Ils conviennent mieux à la vérification des parcours d'applications tels que le processus d'inscription ou de paiement. Plus la fonctionnalité est complexe, plus cette stratégie de test est utile.
+
+Les design system contiennent des composants atomiques dotés d'une fonctionnalité relativement simple. La validation des parcours utilisateurs est souvent exagérée pour cette tâche, car les tests sont longs à créer et difficiles à maintenir. Toutefois, dans de rares cas, les composants peuvent bénéficier de tests end-to-end. Par exemple, la validation d'interfaces utilisateur complexes telles que les sélecteurs de date ou les formulaires de paiement autonomes.
+
+## Favoriser la prise en main grâce à la documentation
+
+Un design system n'est pas complet si l'on se contente de tests. Étant donné que les design system sont au service des acteurs de l'ensemble de l'équipe, nous devons enseigner aux autres comment tirer le meilleur parti de nos composants d'interface utilisateur bien testés.
+
+Dans le chapitre 6, nous apprendrons comment faciliter la prise en main des design system grâce à la documentation. Découvrez pourquoi Storybook Docs est l'arme secrète pour créer une documentation complète en un claquement de doigts.
diff --git a/content/design-systems-for-developers/react/fr/workflow.md b/content/design-systems-for-developers/react/fr/workflow.md
new file mode 100644
index 000000000..66f5fda81
--- /dev/null
+++ b/content/design-systems-for-developers/react/fr/workflow.md
@@ -0,0 +1,257 @@
+---
+title: 'Flux de travail pour les design system'
+tocTitle: 'Flux de travail'
+description: "Un aperçu du flux de travail d'un design system pour les développeurs frontend"
+commit: '9d13d12'
+---
+
+La manière dont les outils frontend fonctionnent ensemble a un impact significatif sur la valeur finale que les équipes de design et de développement peuvent réaliser. S'il est bien fait, le développement et la réutilisation des composants UI devraient se faire en toute transparence.
+
+Ce chapitre présente le flux de travail en cinq étapes en introduisant un nouveau composant, AvatarList.
+
+
+
+## Construire
+
+`AvatarList` est un composant qui affiche plusieurs Avatars. Comme les autres composants du design system, `AvatarList` a commencé par être réutilisé dans de nombreux projets, et c'est la raison pour laquelle il mérite d'être inclus dans le design system. Supposons que le composant ait été développé dans un autre projet et passons directement au code final de cette démonstration.
+
+
+
+Tout d'abord, créez une nouvelle branche dans laquelle nous suivrons ce travail.
+
+```shell
+git checkout -b create-avatar-list-component
+```
+
+Téléchargez le composant `AvatarList` et la story sur votre machine et placez-les dans le dossier `/src/AvatarList` :
+
+- [Fichier du composant](https://raw.githubusercontent.com/chromaui/learnstorybook-design-system/bd9a7647bfa61717c2388153955756e1591227de/src/AvatarList/AvatarList.jsx)
+- [Fichier de la story](https://raw.githubusercontent.com/chromaui/learnstorybook-design-system/bd9a7647bfa61717c2388153955756e1591227de/src/AvatarList/AvatarList.stories.jsx)
+- [Fichier index](https://raw.githubusercontent.com/chromaui/learnstorybook-design-system/bd9a7647bfa61717c2388153955756e1591227de/src/AvatarList/index.js)
+
+
+
+
+
+💡 Storybook est configuré pour détecter automatiquement les fichiers se terminant par `*.stories.js|jsx` et les afficher dans l'interface utilisateur.
+
+
+
+Super ! Maintenant, articulons chaque état de l'interface utilisateur pris en charge par `AvatarList`. A première vue, il est clair que `AvatarList` comporte certaines propriétés de `Avatar` comme `small` et `loading`.
+
+```jsx:title=src/AvatarList/AvatarList.stories.jsx
+export const SmallSize = {
+ args: {
+ ...Short.args,
+ size: 'small',
+ },
+};
+
+export const Loading = {
+ args: {
+ ...Short.args,
+ loading: true,
+ },
+};
+```
+
+
+
+Etant donné qu'il s'agit d'une liste, elle devrait afficher beaucoup d'Avatars. Ajoutons des stories qui illustrent ce qui se passe avec de nombreux éléments et avec peu d'éléments dans la liste.
+
+```jsx:title=src/AvatarList/AvatarList.stories.jsx
+export const Ellipsized = {
+ args: {
+ users: [
+ ...Short.args.users,
+ {
+ id: '3',
+ name: 'Zoltan Olah',
+ avatarUrl: 'https://avatars0.githubusercontent.com/u/81672',
+ },
+ {
+ id: '4',
+ name: 'Tim Hingston',
+ avatarUrl: 'https://avatars3.githubusercontent.com/u/1831709',
+ },
+ ],
+ },
+};
+
+export const BigUserCount = {
+ args: {
+ users: Ellipsized.args.users,
+ userCount: 100,
+ },
+};
+
+export const Empty = {
+ args: {
+ users: [],
+ },
+};
+```
+
+
+
+Sauvegardez vos modifications et validez.
+
+```shell
+git commit -am « Added AvatarList and stories »
+```
+
+## Documenter
+
+Avec la fonction [auto-documentation](https://storybook.js.org/docs/react/writing-docs/autodocs) du Storybook, créer une documentation personnalisable est un jeu d'enfant. C'est un avantage pour ceux qui veulent apprendre à utiliser AvatarList, car ils peuvent facilement se référer à la partie Docs dans l'interface utilisateur de Storybook.
+
+
+
+Et voilà une documentation minimale et utilisable !
+
+Ajoutons à AvatarList un aspect un peu plus humain en fournissant un contexte supplémentaire sur la façon de l'utiliser.
+
+```jsx:title=src/AvatarList/AvatarList.jsx
+/**
+ * A list of Avatars, ellipsized to at most 3. Supports passing only a subset of the total user count.
+ */
+export function AvatarList({ loading, users, userCount, size, ...props }) {}
+```
+
+Ajoutez quelques détails supplémentaires sur les propriétés supportées.
+
+```jsx:title=src/AvatarList/AvatarList.jsx
+AvatarList.propTypes = {
+ /**
+ * Are we loading avatar data from the network?
+ */
+ loading: PropTypes.bool,
+ /**
+ * A (sub)-list of the users whose avatars we have data for. Note: only 3 will be displayed.
+ */
+ users: PropTypes.arrayOf(
+ PropTypes.shape({
+ id: PropTypes.string.isRequired,
+ name: PropTypes.string,
+ avatarUrl: PropTypes.string,
+ })
+ ),
+ /**
+ * The total number of users, if a subset is passed to `users`.
+ */
+ userCount: PropTypes.number,
+ /**
+ * AvatarList comes in four sizes. In most cases, you’ll be fine with `medium`.
+ */
+ size: PropTypes.oneOf(Object.keys(sizes)),
+};
+```
+
+Facile comme bonjour ! Ce niveau de détail est suffisant pour l'instant, nous pourrons toujours personnaliser davantage à l'aide de MDX par la suite.
+
+
+
+La documentation n'a pas besoin d'être fastidieuse. Grâce à des outils automatisés, nous avons supprimé les tâches lourdes pour passer directement à l'écriture.
+
+Effectuez un commit avec les modifications et publiez-les sur GitHub.
+
+```shell
+git commit -am "Improved AvatarList docs"
+```
+
+### Préparer la publication
+
+Avant de publier notre composant dans le design system, nous devons nous assurer qu'il est disponible une fois tout d'installé. Ajoutons-le au fichier`index.js` du design system.
+
+```diff:title=src/index.js
+import * as styles from './shared/styles';
+import * as animation from './shared/animation';
+import * as icons from './shared/icons';
+import * as global from './shared/global';
+
+export { styles, animation, icons, global };
+
+export * from './Avatar';
++ export * from './AvatarList';
+export * from './Badge';
+export * from './Button';
+export * from './Icon';
+export * from './Link';
+export * from './LinkWrapper';
+
+```
+
+#### Créer une Pull Request (PR)
+
+Poussons notre branche `AvatarList` sur GitHub et créons une PR :
+
+```shell
+git push -u origin create-avatar-list-component
+```
+
+Ensuite, allez sur GitHub et ouvrez une PR.
+
+
+
+## Relecture
+
+A ce stade, `AvatarList` est une proposition d'ajout dans le design system.
+Les membres de l'équipe doivent relire le code du composant pour voir s'il répond aux attentes en matière de fonctionnalités et d'apparence. Le Storybook du design system est automatiquement publié avec chaque Pull Request (PR) afin de simplifier la revue. Faites défiler la page jusqu'aux vérifications de la PR pour y trouver un lien vers le Storybook déployé.
+
+
+
+Cherchez `AvatarList` dans votre Storybook en ligne. Il devrait être identique à votre Storybook local.
+
+
+
+Le Storybook en ligne est un point de référence universel pour l'équipe. Partagez le lien vers `AvatarList` avec d'autres membres pour obtenir un retour d'information plus rapide. Votre équipe appréciera parce qu'elle n'aura pas à s'occuper du code ou à mettre en place un environnement de développement.
+
+
+
+Parvenir à un consensus avec de nombreuses équipes ressemble souvent à un exercice futile. Les gens font référence à du code obsolète, n'ont pas d'environnement de développement ou dispersent leurs commentaires dans plusieurs outils. La revue en ligne du Storybook est aussi simple que le partage d'une URL.
+
+## Test
+
+Notre série de tests s'exécute en arrière-plan à chaque validation.
+
+`AvatarList` est un simple composant d'affichage, les tests unitaires ne sont donc pas nécessaires. Mais si nous examinons les vérifications des Pull Request (PR), notre outil de test visuel Chromatic a déjà détecté des changements qui doivent être revus.
+
+
+
+Comme AvatarList est un nouveau composant, il ne possède pas encore de tests visuels. Nous devrons ajouter des références de tests pour chaque story. Accepter les « nouvelles stories » dans Chromatic pour augmenter la couverture des tests visuels.
+
+
+
+Une fois que vous avez terminé, la compilation passera dans Chromatic.
+
+
+
+Ce qui, à son tour, met à jour la vérification de la Pull Request (PR) dans GitHub.
+
+
+
+Les tests ont été mis à jour avec succès. À l'avenir, les régressions auront du mal à se faufiler dans le design system.
+
+## Partager
+
+Nous avons une Pull Request (PR) ouverte qui ajoute `AvatarList` au design system. Nous avons écrit nos stories, les tests sont passés et la documentation existe. Enfin, nous sommes prêts à mettre à jour notre design system avec Auto et npm. Ajouter le label « minor » à la PR. Cela indique à Auto de mettre à jour la version mineure du paquet lors du merge.
+
+
+
+Maintenant mergez votre PR, naviguez vers votre paquet sur npm, et attendez quelques minutes le temps que le paquet se mette mis à jour.
+
+
+
+Bravo ! Le paquet de votre design system a été mis à jour grâce à GitHub. Pas besoin de toucher à la ligne de commande ou de s'occuper de npm.
+
+Mettez à jour la dépendance `learnstorybook-design-system` dans l'application d'exemple pour commencer à utiliser AvatarList.
+
+## Votre voyage commence
+
+_design system for Developers_ met en évidence le flux de travail de bout en bout utilisé par les équipes frontend professionnelles pour vous donner une longueur d'avance lorsque vous développez le vôtre. Au fur et à mesure que votre design system se développe, ajoutez, réorganisez et étendez ces outils pour répondre aux besoins de votre équipe.
+
+Le chapitre 9 se termine par un exemple de code complet, des ressources utiles et une liste de questions fréquemment posées par les développeurs.