Sparking Joy dans un système de conception

Cliquez pour en savoir plus sur l'auteur Marinella Mastrosimone.

Tout développeur front-end aura eu le plaisir d'ouvrir la page nouvellement publiée avec l'inspecteur Chrome et de trouver un code clair et sémantique. Pas même Marie Kondo pourrait faire mieux !

Combien de fois avez-vous examiné un vieux code et pensé : « Mon Dieu, à quel point est-ce grave ? Qui a donné les cours ? Quel gâchis ! » À première vue, cela pourrait être l'œuvre d'un ancien collègue sympathique mais maladroit, mais Git ne ment pas et Visual Studio révèle rapidement l'auteur : Que diable? C'est moi qui ai créé cette obscénité !

Il peut y avoir un côté positif : vous avez amélioré vos compétences au fil du temps et le code que vous écrivez aujourd’hui est plus soigné qu’hier.

Lorsque vous travaillez en équipe sur un produit complexe et en évolution rapide, ce processus individuel a des conséquences néfastes : Un système de nomenclature partagée doit alors être adopté.

« Faire le ménage doit consister à rétablir un équilibre entre les personnes, leurs biens et la maison dans laquelle ils vivent. » –Marie Kondo

Travail d'équipe 

Comme nommer les choses est un talent rare, adopter une convention de dénomination facilite le travail d’équipe et transforme le point d’interrogation géant sur la façon de nommer un objet en un processus automatique qui suit des règles précises et que – au mieux – quelqu’un a défini avant vous.

C'est rassurant d'avoir à la fois un placard bien rangé et un code uniforme, n'est-ce pas ?

"Il n'y a que deux problèmes difficiles en informatique : l'invalidation du cache et la dénomination des choses." –Phil Karlton

Concevoir une interface Penser en BEM

Un concepteur d'interface, capable d'atteindre un bon niveau d'abstraction, peut déjà avoir en tête la structure html des composants lors de leur dessin, du brouillon à Figma.

Après avoir réfléchi sur l'expérience utilisateur et la recherche esthétique de l'interface, le concepteur peut se concentrer sur l'organisation et la dénomination des composants et des niveaux pour préparer le processus de développement du code, en anticipant les problèmes potentiels de développement.

BEM propose un modèle qui permet de raisonner en ces termes : association entre figma et BIEN composant = bloc, couche/groupe = élément variante = identifiant, fonctionne bien.

Tout comme notre mignonne héroïne japonaise suggère d'organiser les espaces de la manière la plus simple possible, en divisant les vêtements selon une logique organisée par type, de même, lors de la conception d'une maquette, il est utile de désencombrer et de regrouper par ensembles et sous-ensembles selon un protocole défini. .

Il est essentiel de discuter avec les techniciens pour valider la faisabilité et la nomenclature, et avec l'aide des collègues FE, de travailler sur des solutions fonctionnelles et partagées pour cette « commode » qui leur servira principalement.

« Les mots peuvent être des balles, mais ils peuvent aussi être des équipes de secours. » –Jón Kalman Stefansson

Qu’est-ce que le BEM ?

BEM est une convention créée en 2007 (lisez ici comment il est né) pour améliorer la collaboration dans le développement front-end.

Grâce à BEM, nous sommes en mesure d'attribuer aux classes de nos éléments DOM des noms explicites sur le type et la hiérarchie de leur contenu :

Block est le conteneur principal qui contient un ensemble d'autres éléments, même à plusieurs niveaux d'imbrication : notre « commode », pour clarifier

Élément est l'enfant du bloc et distingue chacune des sections principales qui contiennent d'autres éléments : la « boîte qui divise les chaussettes », simplement

Identifiant est un indicateur qui change l'apparence du bloc ou de l'élément, comme si les étiquettes des conteneurs transformaient les chemises en pulls en laine

Un exemple : l-header, un composant de notre système de conception, a une structure intrinsèque qui peut contenir des chaînes, des objets ou d'autres composants indépendants.

Architecture CSS robuste

Dans notre entreprise, nous avons choisi BEM comme modèle de référence parmi les nombreuses conventions disponibles (OOCSS, SMACSS, SUITCSS, Atomic) car ses particularités sont parfaitement adaptables aux besoins d'un système de conception :

Structure claire

Avoir une sémantique similaire à la structure React nous permet de penser en termes de composants : chaque composant est un bloc facile à intercepter et à reconnaître au sein du projet également dans le HTML compilé. Voici le l-header compilé. N'est-ce pas beau ?

Modularité

Chaque bloc est composé d'unités distinctes, chacune effectuant une tâche spécifique et capable d'interagir avec les autres, ou d'être utilisée selon des modèles différents.

Vous trouverez ci-dessous notre en-tête L utilisé dans diverses sections de l'interface ARN, notre Plateforme MLOps.

Réutilisable

Chaque composant, tout en conservant ses propriétés, peut changer de forme ou de couleur pour correspondre à son parent ou à son identifiant. C'est ainsi que notre l-header change d'apparence en fonction du contexte et du contenu. Dans ce cas, le produit a la structure de notre système de conception mais en mode lumière et avec une couleur primaire différente dans le produit. Passez en direct.

ABEM : une adaptation utile de BEM 

Distinguer une pièce d'une armoire et une armoire d'un tiroir est naturel lorsque l'on range sa maison. Quand il s'agit d'un système de conception, les choses se compliquent.

Heureusement, certaines spécificités de notre méthode viennent à la rescousse.

Le code partagé jusqu'à présent possède un module de plus que le Block_element-identifier, en fait une déclinaison plus récente appelée ABEM (*) nous permet une classification plus poussée et une plus grande flexibilité.

Un BEM (tomique) définit le type de bloc avec un préfixe d'une seule lettre, tandis que les classes atomique permet l'utilisation de styles globaux, limitant le problème connu de rigidité du système original.

Notre composant pur BEM React aurait pu ressembler à ceci :

Au lieu de cela, nous avons choisi de libérer la classe modificateur de la contrainte du bloc conteneur.

De cette façon, nous pouvons également gérer dynamiquement les classes d’état ou les assistants mieux décrits ci-dessous.

Spécificité du sélecteur

La structure ABEM est extrêmement intéressante grâce à l'ouverture des classes atomiques, mais elle n'est pas assez proche de la solution souhaitée. Pour notre structure, il est idéal d'utiliser le préfixe de nomenclature explicite comme suggéré dans cet article.

Nous pouvons distinguer le type de bloc afin de reconnaître le genre de notre sélecteur :

• Disposition des modules l- l-en-tête l -barre latérale l-modal

Ces modules ne comportent aucun élément esthétique et servent exclusivement à positionner des composants et à structurer l'agencement d'une application.

• Composant c- c-boîte à outils c-détail c-onglet c-bouton
  Ils constituent l’épine dorsale d’une application et contiennent toutes les fonctionnalités d’un composant autonome.
• assistants h- h-montrer h-cacher
  Ces classes utilitaires ont une seule fonction (et sont couramment utilisées pour le positionnement ou la visibilité).
• États est- a- est-visible a-chargé
  Indique les différents états que peut avoir le composant AC.

Sémantique

Maintenant que vous pouvez donner un style soigné à votre projet React, pensez-vous pouvoir éviter de vous demander si l'élément que vous utilisez est un titre, un paragraphe, une étiquette ou une liste ? Se détendre!

Classer chaque objet du dom selon notre modèle ne nous dispense pas de maintenir une sémantique correcte dans le HTML en attribuant la balise appropriée au type de contenu, car la page sans style doit conserver une sémantique correcte. accessibilité – par exemple, pour les systèmes de lecture automatique de codes utiles aux aveugles et les algorithmes de Google, entre autres.

Cohérence des noms

La tâche la plus difficile de toutes : nommer les objets de manière à ce qu'ils soient suffisamment génériques pour être modulaires, tout en conservant la capacité descriptive de leur contenu.

Voulez-vous vraiment appeler « c-consommations » le bloc histogramme qui montre les consommations dans le tableau ? En effet, vous créez ce nouveau composant pour montrer la consommation des clients, mais ce même composant pourrait être utile, par exemple, pour visualiser le détail de l'efficacité d'un service dans un autre environnement où le nom pourrait être trompeur. Appelons-le donc « c-chart-micro » afin d'avoir un niveau de granularité plus large et, éventuellement, faire du graphique un composant interchangeable, avec une zone graphique ou un petit camembert.

« Nomen omen (un nom, un destin) »

Nettoyage de printemps de la base de code

Comme chaque mois d'avril dans les habitudes domestiques de nombreux ménages, c'est l'heure du « nettoyage de printemps » : dans notre entreprise, nous rafraîchissons le système de conception, créons de nouveaux modèles de conception, renouvelons ceux existants et supprimons ceux qui le faisaient. pas « donne-nous de la joie ».

Récemment, nous avons également commencé à déployer de gros efforts pour faire évoluer notre architecture front-end vers une approche « micro-front-end ». Vous voulez en savoir plus ? Restez à l'écoute.

Source : https://www.dataversity.net/sparking-joy-in-a-design-system/