Share
Atomic Design is een methodiek die een zinvolle codestructuur voor stylesheets beschrijft. Het heeft een grote aanhang, maar ik vind dat de naamconventies soms dubbelzinnig kunnen zijn. Wat is een molecuul? Wat is een organisme? Hoe weten we waar de grens tussen de twee te trekken? Deze specifieke vragen lijken het grootste struikelblok te zijn voor het interpreteren van een atomaire architectuur.
Atomen, moleculen, organismen, sjablonen en pagina'sVandaag zullen we bespreken wat ik gebruik, bepaalde facetten van atomaire ontwerpconventies waarmee ik worstel, wat ik heb gedaan om mijn problemen op te lossen, en hoe ik momenteel Sass organiseer met behulp van bijvoorbeeld het 7-1 patroon.
Brad Frost, auteur van Atomic Design, heeft sindsdien verduidelijkt dat zijn methodologieën niet echt een CSS-structuur dicteren. In plaats daarvan biedt het een mentaal model om na te denken over het bouwen van gebruikersinterfaces. Sorry Brad!
"We ontwerpen geen pagina's, we ontwerpen systemen van componenten." - Stephen Hay
Ik ben dol op atomair ontwerp en zijn ideologieën, maar ik heb ontdekt dat ze kunnen instorten wanneer ze werken met teamleden die niet goed bekend zijn met hoe het allemaal werkt. In het verleden heb ik de volgende mapstructuur gebruikt:
Folder Organisatie: root / css / src /
- vars - functies - mixins - basis - plug-ins - typografie - atomen - moleculen - organismen - sjablonen - pagina's - statussen - utiliteitsstijl.scss
Binnen style.scss Sass-gedeelten worden geïmporteerd met behulp van gulp-sass-glob-import:
Sass Import Index-bestand: root / css / src / style.scss
// Config @ import "vars / *"; @import "-functies / *"; @import "mixins / *"; // Bower Components @import "... / bower_components / normalize-scss / _normalize"; // Algemene DOM-selectorstijlen @import "base / *"; // Fonts & General Type Styling @import "typography / *"; // 3rd Party Addons @ import "plug-ins / *"; // Atomic Design @import "atoms / ** / *"; @import "-moleculen / ** / *"; @import "organismen / ** / *"; @import "-sjablonen / ** / *"; @import "pagina's / ** / *"; // Variaties via Events @import "states / *"; // Algemene UI Helpers @import "utility / *";
De volgorde met deze opstelling is nogal belangrijk. Als een "atoom", "molecuul" of "organisme" moet worden aangepast, hebben verklaringen in sjablonen of pagina's voorrang boven de bovengenoemde delen, samen met alle andere gedeeltelijke voorafgaande.
De volgorde maakt bovendien overschrijvingen mogelijk naar de styling van een plug-in, mocht dat nodig zijn (en meestal gebeurt dit in mijn ervaring).
Veel van de inhoud voor elke atoomdirectory (atomen, moleculen, organismen, sjablonen, pagina's) bevat gedeelten die in theorie gemakkelijk te vinden en gemakkelijk beheersbaar zijn wanneer nodig.
- atomen - _buttons.scss - _links.scss - _inputs.scss - molecules - _navigation.scss - _search-form.scss - _contact-form.scss - organismen - _header.scss - _footer.scss - _content.scss - sjablonen - _sticky- footer.scss - _grid-2column.scss - _grid-3column.scss - pagina's - _home.scss - _about.scss - _contact.scss
De organisatie lijkt verstandig als je verstandig bent met atomair ontwerp, maar schiet tekort voor iemand die onbekend is met de aanpak en naamgeving. Een ontwikkelaar die zich niet bewust is van Atomic Design zal geen begrip hebben van het feit dat een zoekformulier binnen de moleculen directory, en kan het zoeken op andere gebieden in gang zetten om bewerkingen uit te voeren, of gewoon gefrustreerd raken en een nieuw bestand maken; Ik heb het gezien.
Vanaf het moment van schrijven gebruik ik een benadering waarbij elementen volledig als componenten worden beschouwd, zoals legoblokken, waardoor een gebruiksgemak wordt gecreëerd voor alle betrokkenen bij de codebase. Bekijk de volgende directorystructuur:
- vars - functies - mixins - basis - typografie - plug-ins - toolbox - componenten - layout - pagina's - states - utility style.scss
Hopelijk kun je aan dit voorbeeld zien dat het redelijk intuïtief is om het doel van elke map te verzamelen (met uitzondering van de toolbox). "Toolbox" is een plaats om helpers op te slaan die niet gerelateerd zijn aan hulpprogramma's, zoals aangepaste klassen voor lay-out- en objectpatronen, aangepaste hoofdframe-animaties, enzovoort. Deze toolbox-items eindigen voor mij meestal als onderdelen die ik in de toekomst misschien zal negeren of misschien willen, en waarom ze voor de componenten-directory worden geïmporteerd.
In dit stadium worden deelpartijen als volgt in de index van de stijlen geladen:
// Config @ import "vars / ** / **"; @import "-functies / *"; @import "mixins / *"; // UI @import "... / bower_components / normalize-scss / _normalize"; @import "base / *"; // algemene stijl met behulp van DOM-elementselectors @import "typography / *"; @import "plug-ins / ** / *"; // invoegtoepassingen van derden @import "toolbox / ** / *"; // Niet-hulpprogrammahelpers @import "componenten / ** / *"; // lego blokkeert layout @import "/ ** / *"; @import "pagina's / ** / *"; @import "states / ** / *"; @import "utility / ** / *";
"Componenten" bevat stukken van de gebruikersinterface, zoals knoppen, ingangen, logo's, avatars, koptekst, voettekst, formulieren en zelfs modules zoals navigatie. Componenten kunnen van alles zijn, zolang ze maar één ding en één ding doen, herbruikbaar zijn, hergebruikt in het hele project en vooral onafhankelijk; geen slechte definitie om universeel begrepen te worden als je het mij vraagt. Deze specifieke aanpak implementeert ook verschillende ideeën van SMACSS (staten) en Atomic Design (sjablonen - lay-out genoemd in dit voorbeeld - en pagina's).
In termen van het vinden van de weg is het veel gemakkelijker om de componenten-map te vinden en het correlerende interface-gedeelte te vinden dat een ontwikkelaar kan opsporen; bijvoorbeeld:
- componenten - _buttons.scss - _navigation.scss - _masthead.scss - _footer.scss - _logo.scss - _avatar.scss - _contact-form.scss - _sales-calculator.scss
Componenten zijn in essentie een one-stop-shop. Atoomontwerp zou perfect kunnen werken voor een team van één of zelfs een team dat heel vertrouwd is, maar binnen een groter team kan de frustratie voelbaar zijn.
Atomic Design kan absoluut worden gebruikt om minimale styling op elementen te behouden om zinvolle en herbruikbare interfacecomponenten te creëren. Maar je vindt bepaalde aspecten misschien verwarrend. Bepaal zelf wat het beste voor u werkt en maak daaruit conclusies. Zoals met alles, is dit slechts mijn ervaring en kunnen anderen een andere mening hebben.
Ik hoor graag hoe je dit scenario zelf benadert, dus laat me dit weten in de reacties. Gelukkig iedereen coderen!
Accentsconagua