Structuring Sass Dire addio all'ambiguità del design atomico

Atomic Design è una metodologia che descrive una struttura di codice sensata per i fogli di stile. Ha un grande seguito, ma trovo che le sue convenzioni di denominazione possano essere talvolta ambigue. Cos'è una molecola? Cos'è un organismo? Come sappiamo dove tracciare la linea tra i due? Queste particolari domande sembrano essere il più grande ostacolo per interpretare un'architettura atomica. 

Atomi, molecole, organismi, modelli e pagine

Oggi discuteremo di quello che uso, particolari aspetti delle convenzioni del design atomico con cui lotto, che cosa ho fatto per risolvere i miei problemi e come attualmente organizzo Sass usando, ad esempio, il modello 7-1.

Nota dell'editore

Brad Frost, autore di Atomic Design, ha poi chiarito il fatto che le sue metodologie non dettano effettivamente alcuna struttura CSS. Invece, offre un modello mentale per pensare a costruire interfacce utente. Scusa Brad!

Struttura atomica

"Non stiamo progettando pagine, stiamo progettando sistemi di componenti." - Stephen Hay

Adoro il design atomico e le sue ideologie, ma ho scoperto che possono crollare quando si lavora con membri del team che non hanno familiarità con il funzionamento di tutto ciò. In passato ho usato la seguente struttura di cartelle:

Organizzazione cartelle: radice / css / src /

 - vars - funzioni - mixins - base - plugin - tipografia - atomi - molecole - organismi - modelli - pagine - stati - utility style.scss

Entro style.scss I partial Sass vengono importati usando gulp-sass-glob-import:

File indice di importazione Sass: radice / css / src / style.scss

// Config @import "vars / *"; @import "funzioni / *"; @import "mixins / *"; // Bower Components @import "... / bower_components / normalize-scss / _normalize"; // stili di selezione DOM generali @import "base / *"; // Caratteri e tipo di carattere generale @import "typography / *"; // Componenti aggiuntivi di terze parti @import "plugins / *"; // Atomic Design @ import "atomi / ** / *"; @import "molecules / ** / *"; @import "organismi / ** / *"; @import "templates / ** / *"; @import "pages / ** / *"; // Variations thru Events @import "states / *"; // General UI Helpers @import "utility / *";

L'ordine con questa configurazione è abbastanza importante. Se un "atomo", "molecola" o "organismo" ha bisogno di essere aggiustato, le dichiarazioni fatte in modelli o pagine annulleranno le parti sopra menzionate, insieme a tutte le altre parziali precedenti. 

L'ordine consente inoltre di eseguire l'override dello stile di un plug-in, se necessario (e in genere nella mia esperienza).

Contenuto della directory

Gran parte del contenuto di ogni directory atomica (atomi, molecole, organismi, modelli, pagine) conterrà parziali che, in teoria, sono facili da trovare e facilmente gestibili quando necessario.

 - atomi - _buttons.scss - _links.scss - _inputs.scss - molecules - _navigation.scss - _search-form.scss - _contact-form.scss - organismi - _header.scss - _footer.scss - _content.scss - templates - _sticky- footer.scss - _grid-2column.scss - _grid-3column.scss - pages - _home.scss - _about.scss - _contact.scss

L'organizzazione appare sensata se sei saggio con Atomic Design, ma non è all'altezza di qualcuno che non ha familiarità con l'approccio e la nomenclatura. Uno sviluppatore ignaro di Atomic Design non ha senso del fatto che un modulo di ricerca risieda all'interno del molecole directory, e può avviare la ricerca in altre aree per apportare modifiche, o semplicemente frustrarsi e creare un nuovo file; L'ho visto accadere. 

Una struttura di componenti

Al momento della stesura di questo libro, prendo un approccio che prevede elementi interamente come componenti, come i blocchi lego, creando in tal modo una facilità di utilizzo per tutti coloro che sono coinvolti con il codice base. Dai un'occhiata alla seguente struttura di directory:

 - vars - funzioni - mixins - base - tipografia - plugin - toolbox - componenti - layout - pagine - stati - utility style.scss

Si spera che in questo esempio si possa vedere che è abbastanza intuitivo raccogliere lo scopo di ciascuna cartella (ad eccezione degli strumenti). "Toolbox" è un posto in cui archiviare helper non correlati alle utilità, come classi personalizzate per layout e modelli di oggetti, animazioni di fotogrammi chiave personalizzati e così via. Questi elementi degli strumenti, di solito, finiscono per essere parti che posso sostituire o potrebbero volere in futuro e perché vengono importati prima della directory dei componenti.

A questo punto i partial vengono caricati nell'indice degli stili in questo modo:

// Config @import "vars / ** / **"; @import "funzioni / *"; @import "mixins / *"; // UI @import "... / bower_components / normalize-scss / _normalize"; @import "base / *"; // stile generale usando selettori di elementi DOM @import "typography / *"; @import "plugins / ** / *"; // Componenti aggiuntivi di terze parti @import "toolbox / ** / *"; // Helpers non-Utility @import "components / ** / *"; // blocchi lego @import "layout / ** / *"; @import "pages / ** / *"; @import "afferma / ** / *"; @import "utility / ** / *";

"Componenti" conterrà pezzi dell'interfaccia utente come pulsanti, input, loghi, avatar, intestazione, piè di pagina, moduli e persino moduli come la navigazione. I componenti possono essere qualsiasi cosa, purché facciano una cosa e una sola cosa, riutilizzabili, riutilizzati attraverso il progetto e soprattutto indipendenti; non una cattiva definizione per essere universalmente compresa se me lo chiedi. Questo particolare approccio implementa anche varie idee da SMACSS (stati) e Atomic Design (template-chiamato layout in questo esempio e pagine).

In termini di modalità di ricerca, è molto più semplice individuare la directory dei componenti e trovare la parte di interfaccia correlata a cui uno sviluppatore potrebbe rintracciare; per esempio:

 - componenti - _buttons.scss - _navigation.scss - _masthead.scss - _footer.scss - _logo.scss - _avatar.scss - _contact-form.scss - _sales-calculator.scss

Essenzialmente, i componenti sono uno sportello unico. Il design atomico potrebbe funzionare perfettamente per una squadra di una, o anche una squadra che è intimamente familiare, ma all'interno di una squadra più ampia, la frustrazione può essere avvertita.

Conclusione

Atomic Design può essere assolutamente utilizzato per mantenere uno stile minimo sugli elementi al fine di creare componenti dell'interfaccia significativi e riutilizzabili. Ma potresti trovare alcuni aspetti confusi. Decidi tu stesso cosa funziona meglio per te e trarre conclusioni da ciò. Come tutto, questa è solo la mia esperienza e altri potrebbero avere una posizione diversa. 

Mi piacerebbe sapere come ti avvicini a questo scenario, quindi fammelo sapere nei commenti. Felice codifica tutti!