Vendredi soir, une barre d'onglets d'Orochia, notre plateforme vidéo pour créateurs, affichait un petit ascenseur vertical à droite. Un pixel de trop, à cause de l'anneau de focus. Un détail. Mais le même motif se retrouvait dans la navigation des réglages, dans une rangée de vidéos courtes, dans un sélecteur de dates et dans la table des matières des pages de lecture.
La correction a été faite une fois, dans le kit (krizaka-ui#295), avec des tests qui échouaient avant. Ensuite, chaque application l'a reçue en montant de version. C'est ça, l'idée d'un kit partagé. Voici ce qu'il donne vraiment chez nous, chiffres à l'appui, et ce qui coince encore.
Un kit, trois plateformes
Krizaka UI est la bibliothèque de composants de tous nos sites et applications. Elle vise trois plateformes : le web (React), le mobile (React Native avec Expo) et le Mac (une fenêtre Tauri, qui affiche les composants web tels quels, avec quelques formes propres au bureau).
Le 17 octobre, la page des plateformes compte 156 composants sur le web, 79 sur le mobile et 112 sur le Mac. La veille, c'était 151, 76 et 107. Ça bouge vite, et c'est voulu.
La règle qui compte le plus n'est pas un composant, c'est une décision : chaque composant doit dire, pour chaque plateforme, s'il y existe, s'il reste à faire (avec un ticket), ou s'il n'a pas de sens là (et quoi utiliser à la place). Un nouveau composant sans cette décision fait échouer les tests (krizaka-ui#283). Côté mobile, il reste 22 trous à combler. Je préfère les voir écrits que les découvrir dans une app.
Le même contrat, pas le même code
Réutiliser un composant, ce n'est pas copier son code d'une plateforme à l'autre. C'est garder la même interface : le même nom, les mêmes variantes, les mêmes couleurs tirées des mêmes jetons de design. Sur le web :
import { Button } from "@krizaka/ui/button";
<Button variant="primary" shape="cut">Continuer</Button>;Et sur le mobile :
import { Button } from "@krizaka/ui/native";
<Button variant="primary" label="Continuer" />;Vous voyez la petite différence : le texte passe par label sur le mobile. Ce n'est pas parfait, et je le dis. Mais une personne qui connaît le bouton du web sait déjà utiliser celui du mobile.
Ce que ça rapporte
Une correction faite une fois. L'ascenseur des onglets en est un exemple. Un autre : sur la page d'accueil de krizaka.com, les cartes d'une même rangée n'alignaient pas leurs liens quand les phrases avaient des longueurs différentes. On a corrigé la carte dans le kit (krizaka-ui#187), avec un test qui mesure la rangée dans un vrai navigateur. Toutes les grilles de cartes de tous les sites en ont profité.
Moins de choses faites à la main. Ce blogue avait son propre pied de page, fait maison. Il utilise maintenant celui du kit (krizaka-blog#21), le même que les autres sites de Krizaka. Pour les tableaux et les formulaires, une règle de lint refuse ceux qu'on écrit à la main hors du kit, et un compteur garde le nombre d'exceptions : il ne peut que baisser.
Des tests à un seul endroit. Le 16 octobre, les registres du kit tournaient 1 682 tests pour les composants et 237 pour les graphiques. Une application n'a pas à retester le comportement d'un bouton, elle teste ce qu'elle en fait.
Ce que ça coûte
Le kit a lui aussi un prix, et je préfère le dire.
Il faut publier, puis faire monter chaque application. @krizaka/ui a connu 48 versions publiées depuis sa création le 8 octobre. Le 17 octobre, 22 fichiers package.json de nos dépôts en dépendaient, et 8 avaient au moins une version mineure de retard. Un correctif dans le kit n'est pas encore un correctif dans l'app.
Les captures de référence. Chaque composant a des captures d'écran qu'on compare à chaque changement, sous Linux et sous macOS, et il faut les régénérer quand le rendu change pour de bon. C'est lent, et ça demande une machine qui n'est pas déjà occupée.
La parité native. 22 trous, c'est 22 endroits où une app mobile doit attendre, ou faire autrement. Et il y a des différences de contrat, comme le label du bouton, qu'on paiera tôt ou tard.
Ce que vous pouvez en retenir
Si vous construisez plusieurs produits, faites un kit tôt, mais traitez-le comme un produit : des tests à lui, une page qui dit honnêtement où chaque composant existe, et un outil qui vous dit quelles applications sont en retard. Gardez les interfaces identiques d'une plateforme à l'autre, même quand le code ne peut pas l'être. Et quand vous corrigez un détail dans une app, demandez-vous d'abord s'il n'existe pas ailleurs.
Le prochain billet de cette série parle de ce qu'on ne voit pas dans le code : les comptes, les clés et l'automatisation qu'il faut pour faire tourner tout ça quand on est seul.
