L’informatique d’aujourd’hui passe avant tout par le Web, que ce soit dans le cadre de simples sites vitrines, d’applications complètes, d’intranet, de sites mobiles ou d’applications desktop (via par exemple Electron), les possibilités sont aujourd’hui quasiment infinies.

Afin d’accélérer les développements, les développeurs s’appuient régulièrement sur des librairies externes dont le type varie, allant de la simple librairie CSS permettant le développement de ses propres composants en s’appuyant sur des classes CSS correspondant à des règles de design préétablies, ou encore de véritables librairies de composants, permettant aux développeur d’utiliser des composants déjà tout prêts à être intégrés dans leurs applications avec leur propre style et logique de fonctionnement.

La problématique est que si ces Framework CSS ou librairies de composants répondent à la majorité des cas d’usage par exemple pour des applications internes ou encore des sites simples, on peut rapidement avoir tendance, dans le cadre d’une application publique censée représenter une société, marque ou produit, à vouloir personnaliser le design ou le comportement de ces composants.

Cela peut être rapide et relativement simple lorsque l’on travaille sur une seule application, mais dans la cadre où votre société ou votre équipe aurait la volonté de pouvoir développer rapidement de nombreuses applications liées (ou pas) basées sur le même design / comportement, ces librairies peuvent rapidement devenir limitantes.

Design System

Pour vulgariser, un Design System définit un ensemble de règles et/ou ressources représentant un design, une charte graphique, mais également le comportement attendu des composants d’une application (ou autre).

Il se représente à tous les stades de développement d’une application, par exemple par des fichiers de design Figma/XD ou autre, par un document de design reprenant de nombreuses images, règles et schémas de comportement des différents composants d’une application, ou directement par le code qui donnera vie à nos composants au sein de notre application.

Dans cet article, c’est le dernier cas qui m’intéresse, et en partant du principe que vos développeurs travaillent sur une application React, Angular, Vue ou tout autre framework ou librairie front, ils ont déjà l’habitude de travailler en mode composants. Si réaliser un design system est une chose qui demande déjà beaucoup de compétences et de ressources UI/UX le but n’est pas que les composants réalisés restent simplement dans leur coin de l’application.

Rappelons que la réalisation d’un Design System à la main veut nécessairement dire créer des composants qui auront leur propre design et leur propre comportement, et le but est que ces composants puissent être utilisés dans toute notre / toutes nos applications en un minimum d’effort.

Pour se faire, les composants, ont besoin d’être référencés et consultables à un endroit où tous peuvent y accéder. UI/UX afin de valider le design demandé, nouveaux comme anciens développeurs afin de pouvoir rechercher et tester les composants qui leurs sont disponibles, ou encore développeurs d’autres applications afin de pouvoir utiliser le Design System que nous avons réalisé dans leurs propres réalisations, au lieu de réinventer la roue pour chaque nouvelle application.

Storybook

Storybook est un projet open-source permettant de faire tout ce dont nous avons parlé dans les précédentes sections : lister des composants, en exposer les propriétés, permettre de les tester et de les manipuler, ainsi que d’en voir la documentation et la manière de les utiliser.

Le fonctionnement de Storybook est simple : à côté de chaque composant d’une application que l’on souhaite exposer, on créera un fichier de Story, dans lequel seront décrites les propriétés du composant, la manière de les utiliser, quelques exemples de code, etc…

Ces fichiers seront ensuite lus au démarrage de l’application Storybook, qui s’occupera de générer une interface Web permettant l’accès et l’essai de nos composants.

Une note importante est que Storybook vit à côté de votre projet applicatif, ce qui veut dire que jamais il ne rentrera en conflit avec votre cycle applicatif, votre CI/CD ou votre application, il se décompose réellement comme une commande console à lancer pour permettre de démarrer l’application Storybook qui analysera les fichiers de votre projet.

Il est important également de noter que Storybook peut s’installer sur un projet existant, et qu’il n’a en aucun cas besoin que tous les composants de votre application possèdent des Story afin d’en afficher d’autres, ce qui peut permettre une adoption progressive de la techno.

Un explorateur de composants d’interface pour les développeurs frontaux

Storybook est un outil qui peut vous permettre d’apporter à votre stack applicative une fenêtre vers les différentes briques la composant, le tout avec une possibilité d’adoption progressive. Du fait de sa philosophie, il peut également vous permettre d’apporter à votre application un semblant de structure et de propreté. Sachant que vous avez la possibilité de le mettre en place progressivement sur un projet et qu’il peut vous faciliter la vie aujourd’hui pour les prochains, pourquoi ne pas l’essayer ?

© Julien PONTILLO | Consultant & expert Klanik