Fermer

mars 19, 2021

Composants compatibles avec le système de conception de bâtiments


Un système de conception vous permet de créer une application Web moderne avec une apparence et un comportement cohérents sans débat ni itération. Et les composants sont les éléments de base parfaits pour votre système de conception.

Comment créer une application Web «moderne» avec une apparence et un comportement cohérents tout en évitant les débats et les itérations interminables pour déterminer les couleurs à utiliser, la taille de vos en-têtes ou comment les commandes comme les boutons doivent-elles se comporter?

Si vous avez déjà passé plus de quelques minutes à rechercher une ligne insaisissable de CSS juste pour faire en sorte que l'en-tête «semble correct», vous savez combien de temps cela peut vous prendre, et à quelle vitesse il peut se transformer en heures de bricolage, d'obtention de commentaires et de modifications jusqu'à ce que tout le monde soit heureux.

Heureusement, il ne doit pas en être ainsi. Il vous faut un système!

Un système pour la conception

Vous avez peut-être entendu parler des «systèmes de conception».

Un système de conception est une tentative de codifier divers aspects de votre application Web conception de telle sorte que les concepteurs, les développeurs et toute autre personne impliquée dans la création de l'application puissent travailler ensemble pour fournir une application qui soit à la fois visuellement et comportementalement cohérente.

À un certain niveau, cela signifie se mettre d'accord sur des choses comme la typographie, les couleurs et les logos.

Mais cela va plus loin que cela, en tenant également compte d'autres aspects de votre application, comme le fonctionnement des interactions (gestes, animations, sons, etc.).

Vous pouvez considérer un système de conception comme une boîte à outils pour votre application. Avec la participation de tout le monde, vous pouvez parvenir à un accord sur de nombreux aspects de l'interface utilisateur de votre application, ce qui vous permet de vous concentrer sur votre code (et d'ajouter de nouvelles fonctionnalités).

Qu'y at-il pour nous les développeurs?

Il est tentant de réfléchir qu'il s'agit avant tout d'un outil pour les concepteurs ou autres parties prenantes pour qui l'apparence et le comportement de l'application sont primordiaux.

Mais en tant que développeur qui a besoin de faire tout ce travail, le système de conception est une réelle opportunité de créer des blocs de construction pour votre application qui permettent de maintenir l'interface utilisateur plus facilement conforme aux attentes de chacun (et cohérente), tout en créant rapidement de nouvelles parties de l'interface utilisateur en composant différentes combinaisons de ces blocs de construction ensemble.

Une façon de penser à la composition de votre UI

Il existe de nombreuses façons de penser aux composants qui forment une application Web, mais je trouve celle qui est particulièrement utile est La méthodologie de conception atomique de Brad Frost .

Il utilise une analogie de chimie pour t hink sur la façon de diviser une conception d'interface utilisateur en plus petits morceaux:

Atoms

Ce sont les éléments de base du Web – ou, comme nous les connaissons, les éléments HTML.

À ce niveau, nous parlons sur des choses comme les formes, les étiquettes, les entrées, etc.

Molécules

Brad décrit les molécules comme une combinaison d'atomes.

Donc, si vous deviez combiner quelques étiquettes et entrées dans une forme, la forme serait un exemple de molécule.

Organismes

C'est ici que nous regroupons les molécules pour former des sections relativement complexes et distinctes de l'interface utilisateur.

C'est ici que vous pouvez créer une bannière, ou un menu de navigation, ou un liste de produits pour votre application.

La clé est que nous prenons nos molécules et les composons ensemble pour former une partie plus concrète de l'interface utilisateur.

Construire un système de conception (en utilisant des composants)

Le bon Cette approche s'intègre très bien avec les frameworks modernes basés sur des composants (tels que React, Angular, Vue, Blazor et autres).

Une fois que nous nous rendons compte que les éléments HTML sont essentiellement des atomes, le travail suivant est de créer des molécules réutilisables.

Il pourrait être utile à ce stade de penser à un exemple concret.

 <  h1 >  Hello World  </  h1 > 

La typographie est probablement le fruit le moins suspendu de la création d'un système de conception.

Afin de créer un système de conception pour votre application, il y aurait une forme de collaboration entre les membres de l'équipe afin de prendre des décisions clés concernant l'apparence et le comportement des éléments constitutifs de base (tels que les en-têtes et les paragraphes).

Une fois ces décisions prises, l'étape suivante consiste à représenter ces décisions d'apparence / comportement dans le code.

À ce stade, vous, en tant que développeur chargé de construire ce système, ayez quelques options.

Tout d'abord, et en particulier pour des choses comme les en-têtes et les polices de paragraphe, vous pouvez définir des styles de typographie de base dans une feuille de style (qui peut ensuite être utilisée dans toute l'application). [19659041] h1 {
font-size : 1.2 em ;
}

h2 {
font-size : 1.1 em ;
}

Cela reste pratique (et par formant) pour prendre soin d'appliquer rapidement les styles de base à votre application.

Mais si le CSS est bon pour contrôler l'apparence de vos éléments d'interface utilisateur (atomes), que se passe-t-il si vous voulez créer quelque chose d'un peu plus complexe?

Encapsulez les éléments clés du système de conception à l'aide de composants

Supposons que vous travaillez sur un site qui affiche de la documentation technique et que le système de conception indique que les termes techniques doivent être mis en évidence pour les faire ressortir.

Une option serait de il suffit d'utiliser directement les balises :

 et c'est ici que nous pouvons utiliser  < code >  window.localStorage  </  code  >  pour stocker les préférences de nos utilisateurs ...

Vous pouvez ensuite utiliser CSS pour styliser toutes les balises code pour les faire sauter de la page.

Mais cette utilisation de la balise brute code souffre de quelques limitations. [19659003] Cela ne fournit pas de contexte supplémentaire sur ce que cela représente réellement (un terme technique), ni ne facilite l'implémentation d'un comportement personnalisé dans toute l'application.

Disons que le système de conception de ce site indique que les utilisateurs devraient pouvoir survoler les termes techniques pour en voir une brève définition.

Si nous n'utilisons que des balises partout, il est difficile d'implémenter ce comportement de survol de manière cohérente sur le site, mais les choses deviennent beaucoup plus faciles lorsque nous créons nos propres composants personnalisés.

Pendant que nous y sommes, nous pouvons donner à nos composants des noms plus spécifiques pour correspondre à la terminologie utilisée dans le système de conception.

 et c'est là que nous pouvons utiliser  < term   definition  =  " Partie de l'API Web Storage qui permet le stockage des paires clé / valeur  " >  window.localStorage  </  term >  to stocker les préférences de nos utilisateurs ...

Nous avons maintenant un composant réutilisable pratique (molécule) qui aura le même aspect et se comportera de manière cohérente dans toute l'application et qui comprend clairement ce qu'il représente.

De plus, si vous vous surprenez à parler de ] window.localStorage plusieurs fois, vous pouvez créer un composant spécifique juste pour ce terme, qui encapsule le composant term sous-jacent…

TermLocalStorage Component

 <  term   definition  =  " Partie de l'API Web Storage qui permet le stockage des paires clé / valeur "  >  window.localStorage  </  terme > 

Ensuite, utilisez-le à plusieurs endroits…

 et c'est ici que nous pouvons utiliser  < termLocalStorage   />  pour stocker les préférences de nos utilisateurs ...

 < termLocalStorage   />  est un moyen très pratique de stocker des préférences utilisateur qui ne sont pas assez permanentes pour être stockées dans une base de données backend ...

Il est toujours facile de modifier le composant terme sous-jacent si le système de conception change, mais vous évitez de dupliquer les mêmes définitions encore et encore sur tout le site.

Styles au niveau des composants

A un élément clé du système de conception réside dans le contrôle de l'apparence d'éléments spécifiques.

Lors de la construction avec des composants, vous avez quelques options pour gérer cela:

  • Définir des styles dans des feuilles de style distinctes
  • Utiliser un framework CSS utilitaire comme TailwindCSS pour styliser des composants individuels
  • Utiliser des styles à portée de composant

The Humble Stylesheet

La première option est celle que nous connaissons probablement tous, pour créer des feuilles de style et les laisser faire tout le travail

La nature du CSS lorsque vous utilisez cette approche est que vous vous retrouvez soit avec des styles qui affectent de nombreux éléments de votre application, soit avec de nombreux sélecteurs d'id / classe pour appliquer des styles plus spécifiques à des éléments individuels (ou à des groupes de éléments) .

 h1  {
    
} 

  # product-listing   .details   {
     
} 

Cependant, lorsque vous travaillez avec des composants, vous voulez souvent que vos styles s’appliquent à des composants spécifiques et éviter que ces styles ne se répandent dans d’autres parties de votre application.

Bien que cela puisse être réalisé avec des sélecteurs d’identités et de classes dans les feuilles de style, cette méthode se transforme souvent en une grande quantité de CSS «colocalisé», qui à son tour conduit souvent à des résultats inattendus, avec des éléments reprenant des styles qui ne leur étaient jamais destinés.

L'alternative est d'isoler (ou d'étendre) vos styles à un composant spécifique. [19659003

Tailwind CSS

Tailwind CSS a gagné du terrain ces derniers temps en tant que moyen pratique de contrôler le style de composants spécifiques (mais sans recourir à aux styles en ligne). ( Lisez les recommandations d'un autre rédacteur Telerik lors de l'utilisation de Tailwind CSS ici. )

Vous pouvez utiliser les classes utilitaires de Tailwind directement dans votre balisage pour contrôler le style des éléments individuels.

Voici à quoi cela pourrait ressembler pour notre term component.

Term Component

 < code   class  =  " px-2 bg-blue- 400 inline-block text-gray-50  " > 
    Le terme va ici (passé en paramètre / prop)
 </  code > 

Ce qui rend ceci dans le navigateur:

 un paragraphe de texte avec un terme technique spécifique mis en évidence

Parce qu'il est parfaitement encapsulé dans un seul composant réutilisable, vous n'avez pas à vous inquiéter à propos de ce balisage spécifique répété plusieurs fois dans l'application (car vous continuerez simplement à réutiliser le même composant term à la place).

Tailwind fournit un moyen rapide d'itérer votre interface utilisateur jusqu'à ce qu'elle corresponde au système de conception vous essayez d'implémenter.

Avec le rechargement à chaud (comme maintenant offert par la plupart des frameworks Web), il est rapide de continuer à peaufiner ces styles jusqu'à ce que vous vous retrouviez avec quelque chose qui vous satisfait.

C'est un peu discordant au début de voir autant de classes dans votre balisage. Mais si vous empruntez cette voie, vous constaterez rapidement que le véritable avantage vient de la facilité avec laquelle il est d'itérer votre interface utilisateur.

Les classes utilitaires de Tailwind sont nommées de manière cohérente afin que vous arriviez rapidement à un point où vous pouvez (généralement avec succès) intuitivement

Par exemple, p- contrôle le remplissage, px- contrôle le remplissage horizontal et py- contrôle le remplissage vertical. À partir de là, il est logique que pl- contrôle le remplissage à gauche, etc.

Isolation CSS spécifique au framework

Les autres options de création de styles spécifiques aux composants varient en fonction du framework que vous utilisez .

Dans tous les cas, vous pouvez définir des styles pour un composant (par exemple, notre composant term ) qui n'affectent que ce composant. Cela vous laisse libre de définir des styles pour les éléments HTML de base dans ces composants (comme les en-têtes, les paragraphes, etc.) sans aucun risque que ces styles «s'échappent» et n'affectent d'autres composants / parties de votre interface utilisateur.

Voici un exemple utilisant Blazor Isolement CSS.

Term.razor.css

 code  {
     background-color :   # 737CA1 ; 
     padding-left :   0,5  rem ; 
     padding-right :   0.5  rem ; 
     color :  white ; 
} 

Term.razor

 < code > 
    @ChildContent
 </  code > 

@code {
[Parameter]
public RenderFragment ChildContent {get; set; }
}

Dans cet exemple, le style que nous avons défini pour le code n'affectera que les utilisations du code dans le composant Terme . Si nous devions déclarer un élément code ailleurs dans l'application, le ou les styles de Term.razor.css ne s'appliqueraient pas.

Bien qu'ils varient légèrement dans la mise en œuvre , tous les frameworks ont des techniques globalement similaires pour définir des styles spécifiques à un composant dans la pratique.

Des molécules plus complexes

En poursuivant avec l'analogie de la chimie, il convient de noter qu'il n'y a pas de réelle limite au nombre de ces blocs de construction (atomes et

Jetez un œil aux commandes dans un système de conception complet tel que Microsoft's Fluent UI et vous verrez que vous pouvez faire un long chemin en définissant ces composants réutilisables et en les utilisant comme épine dorsale de votre interface utilisateur.

Bascules, curseurs, sélecteurs de dates, fil d'Ariane, boutons "J'aime", sélecteurs d'emojis… Tout ce dont vous avez besoin pour votre application, une fois qu'elle est dans le système de conception et que vous avez le composant pour cela, vous êtes libre de l'utiliser où et quand vous aimez créer le reste de votre interface utilisateur.

Interface utilisateur complexe? Composants simples

Alors que vous continuez sur cette voie et que vous vous retrouvez avec votre collection de base de composants réutilisables, ces composants auront (espérons-le) des styles et des comportements très clairs et cohérents (adhérant au système de conception).

Mais qu'en est-il des construire des parties plus compliquées de l'interface utilisateur?

Eh bien, la bonne nouvelle, c'est que vous avez déjà les éléments de base - il s'agit maintenant de les assembler.

Supposons que vous construisez une boutique en ligne et que vous devez afficher une liste des produits.

 une maquette d'une liste de produits montrant un espace réservé pour l'image, le nom du produit et le prix de chaque produit

Vous avez peut-être déjà créé certains des composants dont vous avez besoin (titres, images , boutons). Vous arrivez maintenant à la partie amusante où vous pouvez les composer ensemble pour créer une section distincte plus grande, légèrement plus complexe, de votre interface utilisateur.

Brad Frost appelle ces parties d'interface utilisateur plus complexes organismes .

] C'est à ce moment que vous risquez de vous retrouver à passer de composants généraux réutilisables à des parties plus spécifiques de l'interface utilisateur.

Même dans cet exemple simple, nous commençons à voir l'avantage de créer ces blocs de construction en premier lieu.

Prenons le prix par exemple. Une fois que vous avez un composant price vous pouvez l'utiliser partout et vous assurer que les prix correspondent toujours au système de conception.

 < price   amount  = [19659032] « 121,12 »   /> 

Si le système de conception est mis à jour par la suite pour permettre l'affichage des prix réduits à côté du prix d'origine (avec une grève sur le prix d'origine), vous pouvez étendre ce composant pour gérer les remises et les afficher en conséquence.

 < prix   montant  =  ' 121.12 '   offerPrice  =  ' 89.90 '   /> 

Si toutes les images doivent avoir un texte alternatif, vous pouvez le rendre obligatoire pour votre composant image . Ces images de produit (ainsi que toutes les autres images de votre application) nécessiteront un texte alternatif. [19659003] Si tous les boutons doivent afficher une certaine couleur lorsque vous cliquez dessus, vous pouvez la définir dans votre composant primaryButton et l'oublier (jusqu'à ce que le système de conception change!).

Quand vous empruntez cette voie , vous serez peut-être surpris du peu de travail que vous devez faire sur l'interface utilisateur pour mettre en place de nombreuses parties très différentes de votre interface utilisateur, car vous pouvez utiliser des composants que vous avez déjà construits (ou en créer rapidement de nouveaux).

Attention pour un comportement spécifique s'insinuant dans des composants réutilisables

Pour vous assurer que vos composants sont vraiment réutilisables (comme dans les exemples que nous avons vus ici) et donc des bases solides pour votre système de conception, il vaut la peine d'être conscient de l'endroit où vous placez votre logique.

Dans notre exemple, toute logique propre au produit ct list devrait probablement aller dans le composant Product List (ou organisme), qui est composé des autres composants réutilisables que nous avons explorés. Étant donné que ce niveau de composant est (naturellement) plus concret / spécifique en termes de votre application, il est logique qu'il inclue une logique pour ce cas d'utilisation spécifique.

Mais méfiez-vous de pousser accidentellement une logique contextuelle dans vos composants si vous espère les réutiliser ailleurs.

Si vous vous retrouvez à mettre beaucoup de logique, en particulier du code conditionnel, dans vos composants de niveau inférieur (atomes ou molécules), vous pouvez bien les rendre trop spécifiques à un cas d'utilisation , ou trop génériques dans la mesure où ils essaient de gérer trop de cas à la fois.

Si cela se produit, il y a deux problèmes (et solutions) possibles.

Plusieurs cas d'utilisation traités dans un seul composant

Premièrement , le code conditionnel peut vous indiquer que vous avez besoin d'un autre composant plus spécifique.

Prenez nos humbles titres par exemple.

Si vous avez un composant d'en-tête avec beaucoup de code à gérer, que ce soit un niveau supérieur ou secondaire rubrique (rubrique 1 ou rubrique 2), votre co mponent pourrait en faire trop.

Si tel est le cas, envisagez de créer deux composants, peut-être un primaryHeading et secondaryHeading chacun avec sa propre logique spécifique.

Components Tethered to a Cas d'utilisation spécifique

L'autre possibilité est que votre composant est devenu trop spécifique à un cas d'utilisation.

Pour prendre un exemple un peu idiot (mais quand même assez facile à faire), disons que vous avez modifié votre PrimaryHeading pour faire précéder l'en-tête du mot «Produit», car vous en aviez besoin pour une partie de votre application.

Vous pourriez accidentellement tomber dans le piège consistant à insérer du code conditionnel dans le composant PrimaryHeading pour essayer et afficher / masquer le préfixe «Produit» en fonction d'un autre contexte (par exemple, un indicateur passé au composant).

 < PrimaryHeading   isProduct  =  {true} [19659032]>  Un produit étonnant  </  PrimaryHe ading > 

En réalité, le préfixe «Product» est spécifique au contexte et ne devrait donc probablement pas être dans le composant PrimaryHeading mais contrôlé dans un composant situé plus haut dans l'arborescence des composants.

 <  PrimaryHeading >  Product - Un produit étonnant  </  PrimaryHeading > 

Maintenant, PrimaryHeading ne sait pas si un en-tête doit avoir un préfixe «Produit» ou non!

En général, une bonne règle de base est de garder vos composants concentrés sur un chose bien. S'ils commencent à en faire trop, créez un nouveau composant ou tirez la logique vers le haut de l'arborescence des composants.

Les composants sont les blocs de construction parfaits pour votre système de conception

Les systèmes de conception sont précieux pour toutes les personnes impliquées dans la conception (et la mise en œuvre) une application Web.

L'approche basée sur les composants pour créer des applications Web modernes constitue une solution efficace pour implémenter un système de conception en combinant:

  • Styles généraux (pour la typographie et les styles généraux à l'échelle de l'application)
  • Composants (blocs de construction qui représentent les éléments de base du système de conception)
  • Styles à l'échelle des composants (pour vous assurer que vos composants semblent cohérents dans toute l'application)
  • Interface utilisateur / logique générique et réutilisable dans les composants de niveau inférieur
  • Plus Interface utilisateur concrète et logique dans les composants de niveau supérieur

Avec cette approche, vous pouvez vous concentrer sur la création de parties clés de l'interface utilisateur en utilisant les composants que vous avez déjà construits, en sachant que, comme la conception le système évolue, vos composants aussi.




Source link