Share
Atomic Design est une méthodologie décrivant la structure de code sensible pour les feuilles de style. Il a beaucoup de succès, mais je trouve que ses conventions de nommage peuvent parfois être ambiguës. C'est quoi une molécule? Qu'est-ce qu'un organisme? Comment savons-nous où tracer la ligne de démarcation entre les deux? Ces questions particulières semblent être la plus grande pierre d'achoppement pour interpréter une architecture atomique.
Atomes, molécules, organismes, modèles et pagesAujourd'hui, nous allons discuter de ce que j'utilise, des facettes particulières des conventions du design atomique avec lesquelles je lutte, de ce que j'ai fait pour résoudre mes problèmes et de la façon dont j'organise actuellement Sass en utilisant, par exemple, le modèle 7-1..
Brad Frost, auteur d’Atomic Design, a depuis clarifié le fait que ses méthodologies ne dictent en réalité aucune structure CSS. Au lieu de cela, il offre un modèle mental pour réfléchir à la construction d'interfaces utilisateur. Désolé Brad!
"Nous ne concevons pas de pages, nous concevons des systèmes de composants." - Stephen Hay
J'adore le design atomique et ses idéologies, mais j'ai constaté qu'ils peuvent s'effondrer lorsque je travaille avec des membres de l'équipe qui ne sont pas parfaitement au courant du fonctionnement de tout cela. Dans le passé, j'ai utilisé la structure de dossiers suivante:
Organisation du dossier: root / css / src /
- vars - fonctions - mixins - base - plugins - typographie - atomes - molécules - organismes - modèles - pages - états - style utilitaire.scss
Dans style.scss Les partiels Sass sont importés à l'aide de gulp-sass-glob-import:
Fichier d'index d'importation Sass: root / css / src / style.scss
// Config @import "vars / *"; @import "functions / *"; @import "mixins / *"; // Bower Components @import "… / bower_components / normalize-scss / _normalize"; // Styles de sélecteur DOM généraux @import "base / *"; // Polices & Général Type Styling @import "typography / *"; // Additions tierces @import "plugins / *"; // Conception atomique @import "atomes / ** / *"; @import "molécules / ** / *"; @import "organismes / ** / *"; @import "templates / ** / *"; @import "pages / ** / *"; // Variations à travers les événements @import "states / *"; // Aide de l'interface utilisateur générale @import "utility / *";
L'ordre avec cette configuration est assez important. Si un “atome”, une “molécule” ou un “organisme” doit être ajusté, les déclarations faites dans des modèles ou des pages auront préséance sur les parties susmentionnées, ainsi que sur tous les autres partiels précédents..
La commande permet en outre de remplacer le style d'un plugin, le cas échéant (et le plus souvent selon mon expérience)..
Une grande partie du contenu de chaque répertoire atomique (atomes, molécules, organismes, modèles, pages) contiendra des partiels théoriquement faciles à trouver et faciles à gérer en cas de besoin..
- atomes - _buttons.scss - _links.scss - _inputs.scss - molécules - _navigation.scss - _search-form.scss - _contact-form.scss - organismes - _header.scss - _footer.scss - _content.scss - modèles - _sticky- footer.scss - _grid-2column.scss - _grid-3column.scss - pages - _home.scss - _about.scss - _contact.scss
Si vous êtes avisé d’Atomic Design, l’organisation semble judicieuse, mais elle n’est pas à la portée de quelqu'un qui ne connaît pas l’approche et la nomenclature. Un développeur qui ignore Atomic Design ne comprendra pas qu’un formulaire de recherche réside dans le molécules répertoire, et peut lancer la recherche dans d’autres zones pour apporter des modifications, ou simplement être frustré et créer un nouveau fichier; Je l'ai vu arriver.
Au moment de la rédaction de ce document, j’adopte une approche qui envisage les éléments entièrement comme des composants, comme des blocs lego, créant ainsi une facilité d’utilisation pour tous ceux qui sont impliqués dans la base de code. Examinez la structure de répertoires suivante:
- vars - fonctions - mixins - base - typographie - plugins - outils - composants - mise en page - pages - états - style utilitaire.scss
Espérons que cet exemple montre de manière assez intuitive que le but de chaque dossier (à l’exception de la boîte à outils) est rassemblé. "Boîte à outils" est un emplacement pour stocker des aides non liées aux utilitaires, telles que des classes personnalisées pour la disposition et les modèles d'objet, les animations d'image clé personnalisées, etc. Pour moi, ces éléments de la boîte à outils finissent généralement par être des éléments que je peux remplacer ou souhaiter modifier ultérieurement, et pourquoi ils sont importés avant le répertoire des composants.
A ce stade, les partiels sont chargés dans l'index des styles comme suit:
// Config @import "vars / ** / **"; @import "functions / *"; @import "mixins / *"; // UI @import "… / bower_components / normalize-scss / _normalize"; @import "base / *"; // style général à l'aide de sélecteurs d'éléments DOM @import "typography / *"; @import "plugins / ** / *"; // Add-ons tiers @import "toolbox / ** / *"; // Helpers non utilitaires @import "components / ** / *"; // blocs lego @import "layout / ** / *"; @import "pages / ** / *"; @import "indique / ** / *"; @import "utility / ** / *";
Les «composants» contiennent des éléments de l'interface utilisateur tels que des boutons, des entrées, des logos, des avatars, un en-tête, un pied de page, des formulaires et même des modules tels que la navigation. Les composants peuvent être n'importe quoi, pourvu qu'ils fassent une chose et une seule chose, qu'ils soient réutilisables, réutilisés dans le projet et surtout indépendants. Ce n'est pas une mauvaise définition à comprendre universellement si vous me le demandez. Cette approche particulière met également en œuvre diverses idées de SMACSS (États) et Atomic Design (modèles-appelé mise en page dans cet exemple-et pages).
En termes de recherche de chemin, il est beaucoup plus facile de localiser le répertoire de composants et de trouver la partie d'interface en corrélation qu'un développeur peut rechercher; par exemple:
- composants - _buttons.scss - _navigation.scss - _masthead.scss - _footer.scss - _logo.scss - _avatar.scss - _contact-form.scss - _sales-calculator.scss
Essentiellement, les composants constituent un guichet unique. La conception atomique peut parfaitement fonctionner pour une équipe de un, voire une équipe qui est intimement familière, mais au sein d'une équipe plus grande, la frustration peut être ressentie.
Atomic Design peut absolument être utilisé pour minimiser le style des éléments afin de créer des composants d'interface utiles et réutilisables. Mais vous pouvez trouver certains aspects déroutants. Décidez vous-même ce qui vous convient le mieux et tirez-en des conclusions. Comme pour tout, ceci est juste mon expérience et les autres peuvent avoir une position différente.
J'aimerais savoir comment vous abordez ce scénario vous-même, alors laissez-moi savoir dans les commentaires. Bon codage à tous!
Accentsconagua