Style et CSS

Les feuilles de style en cascade (CSS) sont un langage qui permet de déterminer de manière centralisée la présentation d'un document au lieu de coder en dur le formatage du texte et des objets. La fonctionnalité en cascade du langage est conçue pour contrôler les priorités entre les styles en utilisant l'héritage. Lorsque vous travaillez sur des micro-frontends et que vous créez une stratégie pour gérer les dépendances, la fonctionnalité en cascade du langage peut s'avérer un défi.

Par exemple, deux micro-frontends coexistent sur la même page, chacune définissant son propre style pour l'bodyélément HTML. Si chacun récupère son propre fichier CSS et l'attache au DOM à l'aide d'une style balise, le fichier CSS remplace le premier s'ils ont tous deux une définition d'éléments HTML communs, de noms de classe ou d'ID d'élément. Il existe différentes stratégies pour résoudre ces problèmes, en fonction de la stratégie de dépendance que vous choisissez pour gérer les styles.

Actuellement, l'approche la plus populaire pour équilibrer les performances, la cohérence et l'expérience des développeurs consiste à développer et à maintenir un système de conception.

Systèmes de conception ‒ Une approche axée sur le partage

Cette approche utilise un système pour partager le style le cas échéant, tout en prenant en charge les divergences occasionnelles afin d'équilibrer la cohérence, les performances et l'expérience des développeurs. Un système de conception est un ensemble de composants réutilisables, guidé par des normes claires. Le développement du système de conception est généralement piloté par une seule équipe avec l'apport et les contributions de nombreuses équipes. Concrètement, un système de conception est un moyen de partager des éléments de bas niveau qui peuvent être exportés sous forme de JavaScript bibliothèque. Les développeurs de micro-frontend peuvent utiliser la bibliothèque comme dépendance pour créer des interfaces simples en composant des ressources disponibles prédéfinies et comme point de départ pour créer de nouvelles interfaces.

Prenons l'exemple d'un micro-frontend qui a besoin d'un formulaire. L'expérience typique des développeurs consiste à utiliser des composants prédéfinis disponibles dans le système de conception pour composer des zones de texte, des boutons, des listes déroulantes et d'autres éléments de l'interface utilisateur. Le développeur n'a pas besoin d'écrire de style pour les composants eux-mêmes, mais uniquement pour leur apparence. Le système à créer et à publier peut utiliser Webpack Module Federation ou une approche similaire pour déclarer le système de conception en tant que dépendance externe, de sorte que la logique du formulaire soit empaquetée sans inclure le système de conception.

Plusieurs micro-frontends peuvent alors faire de même pour répondre à des préoccupations communes. Lorsque les équipes développent de nouveaux composants qui peuvent être partagés entre plusieurs micro-frontends, ces composants sont ajoutés au système de conception une fois arrivés à maturité.

L'un des principaux avantages de l'approche du système de conception est le haut niveau de cohérence. Bien que les micro-frontends puissent écrire des styles et parfois remplacer ceux du système de conception, cela n'est pas nécessaire. Les principaux éléments de bas niveau ne changent pas souvent et offrent des fonctionnalités de base extensibles par défaut. Un autre avantage est la performance. Avec une bonne stratégie de création et de publication, vous pouvez produire des ensembles partagés minimaux instrumentés par le shell de l'application. Vous pouvez encore vous améliorer lorsque plusieurs ensembles spécifiques au micro-frontend sont chargés de manière asynchrone à la demande, avec un encombrement minimal en termes de bande passante réseau. Enfin, l'expérience du développeur est idéale, car les utilisateurs peuvent se concentrer sur la création d'interfaces riches sans avoir à réinventer la roue (comme l'écriture JavaScript et le CSS chaque fois qu'un bouton doit être ajouté à une page).

L'inconvénient est qu'un système de conception, quel qu'il soit, est une dépendance, il doit donc être maintenu et parfois mis à jour. Si plusieurs micro-frontends nécessitent une nouvelle version d'une dépendance partagée, vous pouvez utiliser l'une des méthodes suivantes :

• Un mécanisme d'orchestration qui peut parfois récupérer plusieurs versions de cette dépendance partagée sans conflit

• Une stratégie partagée pour déplacer toutes les personnes dépendantes vers une nouvelle version

Par exemple, si tous les micro-frontends dépendent de la version 3.0 d'un système de conception et qu'il existe une nouvelle version appelée 3.1 à utiliser de manière partagée, vous pouvez implémenter des indicateurs de fonctionnalité pour que tous les microfrontends migrent avec un minimum de risques. Pour plus d'informations, consultez la section Feature flags. Un autre inconvénient potentiel est que les systèmes de design ne se limitent généralement pas au style. Ils incluent également des JavaScript pratiques et des outils. Ces aspects nécessitent de parvenir à un consensus par le biais du débat et de la collaboration.

La mise en œuvre d'un système de conception est un bon investissement à long terme. C'est une approche populaire, et elle devrait être envisagée par tous ceux qui travaillent sur une architecture frontend complexe. Cela nécessite généralement que les ingénieurs frontaux et les équipes de produits et de conception collaborent et définissent des mécanismes pour interagir les uns avec les autres. Il est important de prévoir le temps nécessaire pour atteindre l'état souhaité. Il est également important d'avoir le soutien de la direction afin que les gens puissent construire quelque chose de fiable, bien entretenu et performant à long terme.

CSS entièrement encapsulé ‒ Une approche qui ne partage rien

Chaque micro-frontend utilise des conventions et des outils pour surmonter la fonctionnalité en cascade du CSS. Par exemple, assurez-vous que le style de chaque élément est toujours associé à un nom de classe plutôt qu'à l'ID de l'élément, et que les noms de classe sont toujours uniques. De cette façon, tout est limité aux micro-frontends individuels et le risque de conflits indésirables est minimisé. Le shell de l'application est généralement chargé de charger les styles des micro-frontends après leur chargement dans le DOM, bien que certains outils regroupent les styles en utilisant. JavaScript

Le principal avantage de ne rien partager est la réduction du risque d'introduire des conflits entre les micro-frontends. Un autre avantage est l'expérience du développeur. Chaque micro-frontend ne partage rien avec les autres micro-frontends. La publication et le test de manière isolée sont plus simples et plus rapides.

L'un des principaux inconvénients de l'approche « ne rien partager » est le manque potentiel de cohérence. Aucun système n'est en place pour évaluer la cohérence. Même si l'objectif est de dupliquer ce qui est partagé, cela devient difficile lorsqu'il s'agit de trouver un équilibre entre rapidité de publication et collaboration. Une mesure d'atténuation courante consiste à créer des outils pour mesurer la cohérence. Par exemple, vous pouvez créer un système permettant de prendre des captures d'écran automatisées de plusieurs micro-frontends affichées sur une page avec un navigateur sans en-tête. Vous pouvez ensuite consulter manuellement les captures d'écran avant de les publier. Toutefois, cela exige discipline et gouvernance. Pour plus d'informations, consultez la section Équilibrer l'autonomie avec l'alignement.

Selon le cas d'utilisation, les performances constituent un autre inconvénient potentiel. Si toutes les micro-interfaces utilisent une grande quantité de style, le client doit télécharger une grande partie du code dupliqué. Cela aura un impact négatif sur l'expérience utilisateur.

Cette approche consistant à ne rien partager ne doit être envisagée que pour les architectures de micro-frontend qui n'impliquent que quelques équipes, ou pour les micro-frontends qui peuvent tolérer une faible cohérence. Il peut également s'agir d'une première étape naturelle lorsqu'une organisation travaille sur un système de conception.

CSS global partagé ‒ Une approche de partage de tous

Avec cette approche, tout le code lié au style est stocké dans un référentiel central où les contributeurs écrivent du CSS pour tous les micro-frontends en travaillant sur des fichiers CSS ou en utilisant des préprocesseurs tels que Sass. Lorsque des modifications sont apportées, un système de compilation crée un bundle CSS unique qui peut être hébergé dans un CDN et inclus dans chaque micro-frontend par le shell de l'application. Les développeurs de micro-frontend peuvent concevoir et créer leurs applications en exécutant leur code via un shell d'application hébergé localement.

Outre l'avantage évident de réduire le risque de conflits entre les micro-frontends, les avantages de cette approche sont la cohérence et les performances. Cependant, en découplant les styles du balisage et de la logique, il est plus difficile pour les développeurs de comprendre comment les styles sont utilisés, comment ils peuvent évoluer et comment ils peuvent être déconseillés. Par exemple, il peut être plus rapide d'introduire un nouveau nom de classe que de se renseigner sur la classe existante et les conséquences de la modification de ses propriétés. Les inconvénients de la création d'un nouveau nom de classe sont l'augmentation de la taille des ensembles, qui affecte les performances, et l'introduction potentielle d'incohérences dans l'expérience utilisateur.

Bien qu'un CSS global partagé puisse être le point de départ d'une monolith-to-micro-frontends migration, il est rarement bénéfique pour les architectures de micro-frontend impliquant plus d'une ou deux équipes collaborant ensemble. Nous vous recommandons d'investir dans un système de conception dès que possible et de mettre en œuvre une approche de non-partage pendant le développement du système de conception.