Vreugde in een ontwerpsysteem

Klik voor meer informatie over auteur Marinella Mastrosimone.

Elke front-end-ontwikkelaar zal het plezier hebben ervaren van het openen van de nieuw uitgebrachte pagina met de Chrome-inspecteur en het vinden van een duidelijke en semantische, schone code. Zelfs niet Marie Kondo kan beter!

Hoe vaak heb je een oude code bekeken en gedacht: “Goh, hoe erg is dit? Wie heeft de lessen toegewezen? Wat een puinhoop!” Op het eerste gezicht is het misschien het werk van de aardige maar onhandige oud-collega, maar Git liegt niet en Visual Studio onthult snel de auteur: Wat is er in vredesnaam? Ik was het die deze obsceniteit creëerde!

Er kan een positieve kant zijn: je hebt je vaardigheden in de loop van de tijd verbeterd en de code die je vandaag schrijft is netter dan gisteren.

Wanneer je in teamverband aan een complex en snel evoluerend product werkt, eist dit individuele proces zijn tol: Er moet dan een gedeeld nomenclatuursysteem worden ingevoerd.

“Opruimen moet gaan over het herstellen van de balans tussen mensen, hun bezittingen en het huis waarin ze wonen.” –Marie Kondo

Samenspel 

Omdat het benoemen van dingen een zeldzaam talent is, helpt het aannemen van een naamgevingsconventie teamwerk en verandert het gigantische vraagteken over hoe je een object een naam geeft in een automatisch proces dat precieze regels volgt, en dat – in het beste geval – iemand vóór jou heeft gedefinieerd.

Het is geruststellend om zowel een opgeruimde kast als een uniforme code te hebben, nietwaar?

"Er zijn slechts twee moeilijke problemen in de informatica: cache-invalidatie en het benoemen van dingen." –Phil Karlton

Een interfacedenken ontwerpen in BEM

Een interfaceontwerper die een goed abstractieniveau kan bereiken, heeft wellicht al de HTML-structuur van componenten in gedachten bij het tekenen ervan, van het concept tot Figma.

Na te hebben nagedacht over de gebruikerservaring en het esthetisch onderzoek van de interface, kan de ontwerper zich concentreren op het organiseren en benoemen van de componenten en niveaus om het code-ontwikkelingsproces voor te bereiden en te anticiperen op mogelijke ontwikkelingsproblemen.

BEM biedt een model dat helpt om in deze termen te redeneren: associatie tussen figma en WELL component = blok, laag / groep = elementvariant = identificatie, werkt goed.

Net zoals onze schattige Japanse heldin suggereert om ruimtes op de eenvoudigst mogelijke manier te organiseren, door de kledingstukken te verdelen volgens een logica, georganiseerd op type, zo is het ook bij het ontwerpen van een mock-up nuttig om te ontwarren en te groeperen op sets en subsets volgens een gedefinieerd protocol .

Het is essentieel om met de technici te overleggen om de haalbaarheid en de nomenclatuur te valideren, en met de hulp van de FE-collega’s te werken aan functionele en gedeelde oplossingen voor deze ‘ladekast’ die vooral hen van dienst zal zijn.

“Woorden kunnen kogels zijn, maar het kunnen ook reddingsteams zijn.” –Jón Kalman Stefánsson

Wat is BEM?

BEM is een conventie opgericht in 2007 (lees hier hoe het is ontstaan) om de samenwerking bij front-end-ontwikkeling te verbeteren.

Dankzij BEM zijn we in staat om aan de klassen van onze DOM-elementen namen toe te kennen die expliciet zijn over het type en de hiërarchie van hun inhoud:

Blok is de hoofdcontainer die een reeks andere elementen bevat, zelfs op meerdere nestniveaus: onze ‘ladekast’, om te verduidelijken

Element is het kind van het blok en onderscheidt elk van de hoofdsecties die andere elementen bevatten: de ‘doos die de sokken verdeelt’, simpelweg

Identifier is een indicator die het uiterlijk van het blok of element verandert, alsof de labels van de containers de shirts in wollen truien veranderen

Een voorbeeld: l-header, een onderdeel van ons ontwerpsysteem, heeft een intrinsieke structuur die strings, objecten of andere onafhankelijke componenten kan bevatten.

Robuuste CSS-architectuur

Bij ons bedrijf hebben we BEM gekozen als referentiemodel uit de vele beschikbare conventies (OOCSS, SMACSS, SUITCSS, Atomic) omdat de eigenaardigheden ervan perfect aanpasbaar zijn aan de behoeften van een ontwerpsysteem:

Duidelijke structuur

Omdat de semantiek vergelijkbaar is met de React-structuur, kunnen we in termen van componenten denken: elke component is een gemakkelijk blok om binnen het project te onderscheppen en te herkennen, ook in de gecompileerde html. Hier is de l-header samengesteld. Is het niet prachtig?

modulariteit

Elk blok bestaat uit verschillende eenheden, die elk een specifieke taak uitvoeren en in staat zijn om met de anderen te communiceren, of in verschillende patronen te worden gebruikt.

Hieronder vindt u onze l-header die in verschillende secties van de RNA-interface wordt gebruikt, onze MLOps-platform.

herbruikbaarheid

Elke component kan, met behoud van zijn eigenschappen, van vorm of kleur veranderen om overeen te komen met zijn ouder of identificatie. Dit is hoe onze l-header van uiterlijk verandert op basis van context en inhoud. In dit geval heeft het product de structuur van ons ontwerpsysteem, maar dan in de lichtmodus en met een andere primaire kleur in het product Ga leven.

ABEM: een nuttige aanpassing van BEM 

Het onderscheiden van een kamer van een kledingkast en een kledingkast van een la is normaal als we ons huis opruimen. Als het gaat om een ontwerp systeem, worden de zaken ingewikkelder.

Gelukkig komen enkele specifieke kenmerken van onze methode te hulp.

De tot nu toe gedeelde code heeft één module meer dan de Block_element-identifier, in feite een recentere declinatie genaamd ABEM (*) maakt een verdere classificatie en grotere flexibiliteit mogelijk.

Een (tomische) BEM definieert het type blok met een voorvoegsel van een enkele letter, terwijl de klassen atomair maakt het gebruik van globale stijlen mogelijk, waardoor het bekende probleem van de stijfheid van het oorspronkelijke systeem wordt beperkt.

Onze pure BEM React-component had er zo uit kunnen zien:

In plaats daarvan hebben we ervoor gekozen om de modifier-klasse te bevrijden van de beperking van het bevattende blok.

Op deze manier kunnen we ook staatsklassen of helpers dynamisch beheren, zoals hieronder beschreven.

Selectorspecificiteit

De ABEM-structuur is buitengewoon interessant dankzij de openheid van de atomaire klassen, maar komt niet dicht genoeg bij de gewenste oplossing. Voor onze structuur is het ideaal om het voor zichzelf sprekende nomenclatuurvoorvoegsel te gebruiken, zoals voorgesteld in dit artikel.

We kunnen het type blok onderscheiden om het genre van onze selector te herkennen:

• Module-indeling l- l-kop l -zijbalk l-modal

Deze modules hebben geen esthetische elementen en worden uitsluitend gebruikt om componenten te positioneren en de lay-out van een applicatie te structureren.

• Component c- c-toolbox c-detail c-tab c-knop
  Ze vormen de ruggengraat van een applicatie en bevatten alle functionaliteiten voor een standalone component.
• helpers h- h-toon h-verberg
  Deze nutsklassen hebben één enkele functie (en worden vaak gebruikt voor positionering of zichtbaarheid).
• Staten het heeft- is zichtbaar is geladen
  Geeft de verschillende toestanden aan die een AC-component kan hebben.

Semantiek

Nu u uw React-project een nette stijl kunt geven, denkt u dat u zich niet hoeft af te vragen of het element dat u gebruikt een titel, paragraaf, label of lijst is? Ontspan!

Het classificeren van elk object van de dom volgens ons model ontslaat ons niet van de noodzaak om de juiste semantiek in de html te behouden door de juiste tag aan het inhoudstype toe te wijzen, aangezien de stijlvrije pagina correct moet blijven de toegankelijkheid – bijvoorbeeld voor automatische codeleessystemen die onder meer nuttig zijn voor blinden en Google-algoritmen.

Naamgevingsconsistentie

De moeilijkste taak van allemaal: objecten zo benoemen dat ze generiek genoeg zijn om modulair te zijn, terwijl de beschrijvende kracht van hun inhoud behouden blijft.

Wil je echt ‘c-consumpties’ noemen? het staafdiagramblok dat de verbruiken in de tabel weergeeft? U maakt dit nieuwe onderdeel inderdaad om het verbruik van klanten weer te geven, maar hetzelfde onderdeel kan bijvoorbeeld nuttig zijn om de efficiëntiedetails van een dienst in een andere omgeving te visualiseren waar de naam misleidend zou kunnen zijn. Laten we het dus 'c-chart-micro' noemen om een ​​breder niveau van granulariteit te bereiken en eventueel van het diagram een ​​uitwisselbaar onderdeel te maken, met een diagramgebied of een klein cirkeldiagram.

“Nomen voorteken (een naam, een bestemming)”

Voorjaarsschoonmaak van de Codebase

Zoals elk jaar in april is het in de huishoudelijke gewoonten van veel huishoudens tijd voor de “voorjaarsschoonmaak”: bij ons bedrijf vernieuwen we het ontwerpsysteem, creëren we nieuwe ontwerppatronen, vernieuwen we de bestaande en verwijderen we de patronen die dat wel deden. niet ‘geef ons vreugde’.

Onlangs zijn we ook grote inspanningen gaan leveren om onze front-endarchitectuur naar een “micro-front-end”-aanpak te verplaatsen. Wil je meer horen? Blijf kijken.

Bron: https://www.dataversity.net/sparking-joy-in-a-design-system/