Après des années de développement, nous avons décidé de standardiser l'interface utilisateur de l'un de nos produits les plus importants - notre tableau de bord multi-applications.
Nous l'avons fait pour nos clients et utilisateurs internes (facilité d'utilisation) ainsi que pour notre équipe produit (processus de conception, prise de décision et codage plus faciles). Nous devions également nous aligner de manière plus cohérente sur l'image de marque de notre entreprise.
Pour cela, nous avons construit un système de conception interne , appelé Satellite.
Lors du développement de Satellite, nous avons examiné différentes solutions CSS pour la bibliothèque d'interface utilisateur, toutes avec leurs avantages et leurs inconvénients : Saas , modules css , css-in-js .
Après avoir envisagé des frameworks similaires à Bootstrap, nous nous sommes installés sur le framework CSS Tailwind CSS . Pourquoi?
CSS pur (pas d'exécution JS) - bon pour les performances.
A tendance à générer des fichiers de feuille de style CSS plus petits (après la purge) - également bon pour les performances.
Pas de basculement entre un fichier CSS et votre code javascript lors du développement de nouveaux composants.
Pas de temps perdu à essayer de trouver de bons noms pour les classes utilitaires.
Aide à promouvoir la cohérence de l'interface utilisateur.
Vous permet de définir une collection d'espacements et de couleurs qui correspondent bien aux jetons de conception (une "palette restreinte").
Cependant… il y avait un inconvénient à Tailwind : la lisibilité des composants complexes. La soupe de Tailwind peut être difficile à digérer lorsque vous n'êtes pas habitué à ses noms de classe.
Dans notre cas, cela a été aggravé car nous avons dû utiliser une version préfixée des classes CSS ( stl-
) pour éviter les conflits avec notre ancien CSS, ajoutant encore plus de bruit et de longueur à nos chaînes de noms de classe.
Cet article montre comment nous avons atténué le problème de lisibilité. Pour commencer, nous avons utilisé plusieurs techniques de développement Web, telles que les littéraux balisés et l'interpolation, pour raccourcir la longueur de nos chaînes.
Ensuite, nous avons simplifié l'utilisation des noms de classe avec l'outil de linter ESLint, fournissant un meilleur DX avec deux outils :
Un plugin ESLint, car il n'y avait pas de plugin ESLint-Tailwind officiel à l'époque.
Une extension Visual Studio Code pour simplifier l'utilisation en fournissant une intelligence des nombreuses classes de Tailwind. L' extension officielle ESLint VS ne fonctionnait pas pour nous car elle s'attendait à ce qu'un fichier de configuration ( tailwind.config.js
) soit présent dans le projet, alors que nous avions utilisé une version prédéfinie à l'époque. Entre autres tâches, nous avions besoin de VS pour travailler avec notre fichier de configuration.
C'est plus ou moins le contexte. Passons maintenant à la réalisation.
Un framework CSS axé sur les utilitaires comme Tailwind est livré avec un grand nombre de classes utilitaires préexistantes que vous pouvez utiliser directement dans votre code HTML et JavaScript. Ces classes permettent la cohérence dans le code.
Et ils sont entièrement configurables : avec les mêmes noms de classe, nous pourrions facilement marquer notre application avec des variantes. Par conséquent, l'utilisation des noms de classe CSS Tailwind nous a permis de créer un ensemble cohérent de couleurs, d'espacement, de polices - essentiellement, tout ce qui concerne le CSS - et de déployer un système de conception facile à mettre en œuvre.
Nous voulions simplifier notre utilisation des classes de Tailwind.
Pour cela, nous avons utilisé des techniques telles que les modèles littéraux balisés, l'interpolation et les conditions.
Nous avons commencé avec une longue chaîne de classes CSS comme celle-ci :
const className = 'stl-inline-flex stl-items-center stl-justify-center stl-rounded-full stl-h-10 stl-w-10 stl-bg-blue-100';
Mais on s'est vite rendu compte que ce n'était pas facile à lire. De plus, il contenait du bruit inutile, tel que le préfixe stl-
, utilisé pour éviter les conflits avec d'autres classes.
Nous avons donc demandé l'aide de littéraux de modèle balisés pour supprimer le préfixe de la chaîne. Nous avons créé une balise stl
:
const className = stl 'inline-flex items-center justify-center rounded-full h-10 w-10 bq-blue-100';
Le résultat est un morceau de code (CSS) élégant :
const className = stl ' inline-flex items-center justify-center h-10 w-10 ${round && 'rounded-full'} ${iscool ? 'bg-blue-100' : 'bq-red-100'} ;
L'élégance est une chose. Correct en est une autre. Il est facile de mal orthographier les classes, surtout lorsqu'il y a de nombreuses classes à apprendre initialement dans Tailwind.
Voici un exemple de ce qui peut mal tourner :
cost className = stl 'felx space-between text-gray-200';
Pouvez-vous repérer les erreurs?
Nous devions vérifier que les classes utilisées par les gens étaient les bonnes. Nous avons donc utilisé l'outil de linter ESLint pour parser le code, l'analyser et signaler les erreurs.
Nous avons créé un plugin ESLint pour la qualité du code et pour signaler les erreurs sur les noms de classe qui n'existaient pas.
ESLint utilise un arbre de syntaxe abstraite (AST) qui donne accès à des lignes de code individuelles.
L'AST convertit essentiellement les chaînes du code en nœuds, que vous pouvez analyser en tant que collections et éléments.
Voici la répartition de la façon dont ESLint analyse le code. L'expression entière est un node
de type VariableDeclataion
:
Nous voulons analyser l'expression sur le côté droit, le TaggedTemplateExpression
.
Comme vous pouvez le voir, il y a un callback qui gère ce genre d'expression :
Dans le rappel TaggedTemplateExpression
, nous collectons toutes les chaînes de ce modèle. Par exemple:
L' TemplateElement
Les Literals
Une fois la collecte terminée, un autre rappel enregistré parcourt les noms de classe collectés et confirme s'ils existent.
Il le fait avec la collection, validClassNames
:
C'est ça.
Nous avons tout de suite su que la création de ce plugin de validation était la bonne chose à faire, car nous avons effectivement trouvé quelques fautes d'orthographe dans notre système, ainsi que dans la base de code existante du tableau de bord !
Le dernier outil que nous avons créé était une extension dans Visual Studio Code. En utilisant la même logique que dans notre plugin, ESLint suggère des classes de typescript en tant que types de développeur.
Cet intellisense empêche les développeurs de deviner ou d'avoir à se rendre sur le site Web de Tailwind pour rechercher et trouver les bonnes classes.
Comme vous pouvez le voir dans le GIF, non seulement il propose des noms de classes, mais il affiche également les couleurs ou les icônes utiles pour chaque suggestion.
Avec Tailwind CSS et ESLint, nous avons pu faire respecter nos standards (accessibles en interne sur Github) en améliorant le DX dans leur mise en œuvre.