Share
Voor schaalbare front-ends zijn Sass-kaarten een zegen. Het extraheren van de configuratie van de logica van een module is een geweldige methode om te structureren. Laat me u uitleggen waarom ik denk dat Sass Maps de beste functie is in Sass 3.3.
Sass 3.3 is al een tijdje binnen ieders bereik, maar veel van de functies in de echte wereld zijn nog steeds onbekend bij veel ontwikkelaars. De nieuwe versie van Sass heeft ons een nieuw gegevenstype genoemd kaart. Kaarten bevatten een verzameling sleutel / waarde-paren en helpen ons bij het maken van kleine configuratiegebieden voor een vereenvoudigde codebase.
Om bij te zijn, bespreken we de basisprincipes van het gebruik van Sass Maps, en later zullen we enkele gebruikscasussen bekijken.
Hier is een snel overzicht van de syntaxis voor een pittige kaart. Begin met een variabelenaam ($ kaart in dit geval) en voer dan enkele sleutels in met waarden, gescheiden met komma's, allemaal met accolades:
$ map: (key: value, nextkey: nextvalue);
Als u op een bepaald moment meerdere sleutel / waarde-paren heeft opgeslagen, moet u die informatie ophalen. Als u de waarde van een sleutel moet vinden, gebruikt u de functie kaart-get (). We gaan er twee parameters doorgeven: de naam van de kaart en vervolgens de sleutel.
.element: before content: map-get ($ map, key);
Eenmaal gecompileerd zal de uitvoer als volgt zijn:
.element: before content: value;
Het is ten zeerste aan te bevelen dat u een solide foutafhandeling gebruikt in uw Sass-ontwikkelingsproces. Hiervoor geeft Sass ons de functie map-heeft-toets (). Deze helper kijkt of een sleutel bestaat en levert geen andere uitvoer om de ontwikkelaar te waarschuwen.
Bekijk hier An Introduction to Error Handling in Sass van Hugo Giraudel voor een geweldige manier om fouten te verwerken.
$ map: (key: value, nextkey: nextvalue); .element @if map-has-key ($ map, key) content: 'Map heeft deze sleutel.'; @else content: 'Map heeft deze sleutel niet.';
Resultaat:
.element content: 'Map heeft deze sleutel.';
Bonus tijd: Met Sass kunnen we twee of meer kaarten samenvoegen. Je begint dit nu onder de knie te krijgen, dus bekijk dit voorbeeld van hoe je de map-merge () functie:
$ kleuren: (licht: #ccc, donker: # 000); $ merk-kleuren: (hoofd: rood, alternatief: blauw); // Samenvoegen kaarten $ samengevoegd: kaart samenvoegen ($ kleuren, $ merk-kleuren); .element content: map-get ($ merged, alternative);
Het resultaat:
.element inhoud: blauw;
We hebben de hoe, laten we nu kijken naar de waar.
Kaarten kunnen ook handig zijn zonder de bijbehorende functies. U kunt bijvoorbeeld een lus uitvoeren door uw kaart, de parameters definiëren met de waarden die u verwacht en vervolgens de naam van de Sass-kaart toevoegen. Door dit te doen, is het mogelijk om met verschillende soorten waarden te werken.
In dit voorbeeld voer ik klassen uit om pictogrammen weer te geven. Ik zet de naam van het pictogram als de sleutel, waarbij de waarde wordt achtergelaten om de werkelijke op te slaan inhoud (die we dan via pseudo-elementen zouden toevoegen).
Notitie: In een real-world scenario zouden we eerst een aantal basisstijlen declareren, maar dat valt buiten het bestek van deze tutorial.
/ * Definieer de Sassy Map met de naam $ icons * / $ icons: (vinkje: a, plus: b, minus: c); / * Maak voor elke sleutel op de kaart een eigen klasse * / @each $ naam, $ waarde in $ pictogrammen .icon - # $ name content: $ value;
De output spreekt voor zich:
/ * Maak voor elke sleutel op de kaart een eigen klasse * / .icon - vinkje content: "a"; .icon - plus content: "b"; .icon - minus inhoud: "c";
Dit is een zeer efficiënte manier om ladingen klassen voor pictogrammen af te drukken. Er zijn ook veel meer use-cases - laten we eens kijken naar wat.
Verderop is het mogelijk om een sleutel meer dan één waarde te geven. Dit gebeurt door knipsels te gebruiken en meerdere waarden in te voeren met een komma-scheidingsteken. Dit zou bijvoorbeeld geweldig kunnen zijn om stijlen over te dragen voor varianten van een module.
Hier ga ik een reeks knoppen stylen. De eerste waarde voor elke sleutel is voor de Achtergrond kleur en de tweede is voor de font-kleur.
Daarna loop ik door de toetsen met het verwachte object $ kleuren. Ik krijg de waarde van de eerste sleutel in dit object met nth ($ kleuren, 1) (begin met de naam van het object en vervolgens de positie van de gezochte waarde). Als u de tweede waarde nodig heeft, voert u deze in 2.
// _m-buttons.scss $ buttons: (error: (# d82d2d, # 666), success: (# 52bf4a, #fff), waarschuwing: (# c23435, #fff)); .m-knop display: inline-block; opvulling: .5em; achtergrond: #ccc; kleur: # 666; @each $ naam, $ kleuren in $ knoppen $ bgcolor: nth ($ colors, 1); $ fontcolor: nth ($ kleuren, 2); & - # $ name background-color: $ bgcolor; kleur: $ fontcolor;
Het resultaat:
.m-knop display: inline-block; opvulling: .5em; achtergrond: #ccc; kleur: # 666; .m-knop - fout background-color: # d82d2d; kleur: # 666; .m-knop - succes achtergrondkleur: # 52bf4a; kleur: #fff; .m-knop - waarschuwing achtergrondkleur: # c23435; kleur: #fff;
Ik ken geen enkele front-end ontwikkelaar die op een bepaald moment niet met een z-index worstelde. Problemen ontstaan meestal als u een overzicht verliest als u het moet gebruiken z-index op meerdere plaatsen in een project. Sass-kaarten kunnen ons helpen.
Laten we beginnen met $ layer als de kaart. De sleutels moeten logisch worden benoemd, zodat u weet welke waarde voor welk element is - misschien offcanvas, lichtbak, laten vallen enz.
// _config.scss $ layer: (offcanvas: 1, lightbox: 500, dropdown: 10, tooltip: 15); // _m-lightboxes.scss @function layer ($ name) @if map-has-key ($ layer, $ name) @return map-get ($ layer, $ name); @warn "De sleutel # $ naam staat niet op de kaart '$ laag'"; @return null; ; .m-lightbox z-index: layer (lightbox);
Hier schreef ik een functie om de waarde van een specifieke sleutel te krijgen, maar waarom deed ik dat? Het antwoord is gelukkig eenvoudig: het is sneller dan schrijven kaart-get () elke keer. Een ander positief aspect is dat u een foutafhandeling kunt maken en de ontwikkelaar een beetje feedback kunt geven over waarom er niets gebeurt.
Dit is de output:
.m-lightbox z-index: 500;
Elk project heeft zijn eigen configuratiebestand; basis voor wereldwijd gebruik. In mijn projecten definieer ik bijvoorbeeld enkele waarden voor lettertype-eigenschappen: lettertypekleur, alternatieve lettertypekleur, lettertypefamilie of lettertypegrootte. Vroeger maakte ik voor elke woning een variabele, maar een kaart zou beter zijn.
Hier is een snel voorbeeld, om te beginnen met de oud oplossing:
$ base-font-color: # 666; $ base-font-family: Arial, Helvetica, Sans-Serif; $ base-font-size: 16px; $ base-line-height: 1,4;
Dan de nieuwe oplossing met behulp van een Sass-kaart:
// _config.scss $ font: (kleur: # 666, familie: (Arial, Helvetica), grootte: 16px, regelhoogte: 1,4); // _presets.scss body color: map-get ($ font, color); font-family: map-get ($ font, family); font-size: map-get ($ font, size); line-height: map-get ($ font, line-height);
Ik ben dol op deze use-case. Het is fantastisch om een gebied te hebben voor de breekpunten die deel uitmaken van uw hele project. Dus, net als het gedeelte over de afhandeling met z-index, heb je een overzicht van alle gebruikte breekpunten. Als je de waarde daar wijzigt, dan verander je het gedrag gedurende je project. Geweldig.
Laten we beginnen met een kaart met de naam $ breekpunten.
Ons doel is om breekpunten met impliciete namen te gebruiken in plaats van harde pixelwaarden in een element. Daarom hebben we een mix nodig die de waarde van de opgegeven naam zal uitvoeren. Ik heb de mixin gebeld reageren-to en ga voorbij $ breekpunt als een parameter. Met $ value Ik krijg de waarde van het verwachte onderbrekingspunt en zet dit later in de mediaquery.
// Kaart met veel onderbrekingspunten $ onderbrekingspunten: (klein: 320px, gemiddeld: 600px, groot: 768px); // Reageren op Mixin @mixin reageren op ($ breekpunt) @if map-has-key ($ breekpunten, $ breekpunt) $ waarde: map-get ($ breekpunten, $ breekpunt); @media-scherm en (min-breedte: $ waarde) @content; @worden "Onbekend" # $ breekpunt 'in $ breekpunten ";
Voorbeeld:
// Sass .m-tabs background-colour: # f2f2f2; @ inclusief antwoord op (medium) achtergrondkleur: # 666; // Output .m-tabs background-color: # f2f2f2; @media-scherm en (min-breedte: 600px) achtergrondkleur: # 666;
Deze use-case is een van mijn favorieten!
Dingen worden nu een beetje tricker. Laten we eens kijken geneste kaarten-geweldig voor kleurenschema's met een reeks tonen.
Onze Sass-kaart krijgt in dit geval de naam $ colorscheme en het heeft objecten met sleutels en waarden. Het project heeft verschillende grijstinten, maar we willen geen variabele voor elke variabele declareren. Dus we voegen een object toe grijs, knipsels toevoegen en vervolgens de toetsen met waarden.
Begin met een kaart zoals deze hier:
// Schema van kleuren $ colorschema: (grijs: (basis: #ccc, licht: # f2f2f2, donker: # 666), bruin: (basis: # ab906b, licht: # ecdac3, donker: # 5e421c));
Laten we nu de functie toevoegen setcolor voor een kortere weg om onze kleur van keuze te krijgen. De eerste verwachte waarde is het object van de Sass-kaart ($ regeling) - in dit voorbeeld zou het kunnen zijn grijs of bruin. De tweede parameter is de kleur die u wilt ($ tone) - de standaardwaarde hiervoor is de sleutel baseren.
// Onze functie voor korter gebruik van map-get (); @function setcolor ($ scheme, $ tone: base) @return map-get (map-get ($ colorscheme, $ scheme), $ tone);
Ten slotte is hier een voorbeeld van hoe u het kunt gebruiken en hoe u de verschillende kleuren uit de geneste kaart kunt halen. Het is makkelijker dan je denkt (misschien)!
// Sass .element color: setcolor (bruin); .element - licht color: setcolor (bruin, licht); // Output .element color: # ab906b; .element - light color: # ecdac3;
Je hebt de uitdaging voltooid. Nu kunt u een palet maken zonder uw code op te blazen met te veel variabelen voor elk type kleur.
Voor deze techniek werd ik geïnspireerd door Tom Davies en ik raad je aan zijn artikel hierover te lezen.
Nu iets voor geavanceerde Sass-gebruikers. In projecten is het vaak een vereiste om verschillende soorten thema's te maken met dezelfde codebase. Dus hier is een voorstel om een themaklasse boven aan het document in te stellen om een specifieke look toe te passen. We hebben een object nodig waarin we de naam van thema's kunnen verwerken en de verschillende stijlen voor de module kunnen instellen.
Begin met een Sass-kaart en definieer de thema's globaal voor uw project. De waarde is de naam en de klasse, die u moet toevoegen aan de element. In dit voorbeeld heb ik de kaart gemaakt $ thema's met twee varianten: theme-light en theme-dark.
// _config.scss $ themes: (theme1: theme-light, theme2: theme-dark);
Nu hebben we een functie nodig voor een snelle manier om waarden van de modules te krijgen. Het is een korte helper en heeft drie parameters nodig. Dit zijn:
Accentsconagua
$ kaart: Definieer de naam van de kaart waar alle waarden vandaan komen.$ object: In dit geval de sleutel voor het thema.$ stijl: Het eigendom voor de stijl die nodig is.// _functions.scss @function setStyle ($ map, $ object, $ stijl) @if map-has-key ($ map, $ object) @return map-get (map-get ($ map, $ object) , $ stijl); @worden "De sleutel" # $ object is niet beschikbaar op de kaart. "; @return null;
Maak nu een nieuwe Sass-kaart met de naam $ config. Elk thema krijgt een object en de naam moet dezelfde sleutel zijn als waarin u definieert $ thema's: zo niet krijg je een foutmelding.
// _m-buttons.scss // 1.Config $ config: (thema1: (achtergrond: # f2f2f2, kleur: # 000), thema2: (achtergrond: # 666, kleur: #fff));
Eindelijk het stuk met een beetje magie. We beginnen met een module zoals .m-knop en dan willen we een ander uiterlijk creëren in elk thema. Dus we gebruiken @elk met $ key en $ value als verwachte waarden die we van de kaart halen $ thema's. Sass doorloopt nu de toetsen op de kaart en maakt voor elk thema iets.
Aan het begin van dit gedeelte heb ik gezegd dat het noodzakelijk is dat de toetsen op elke kaart hetzelfde zijn ($ thema's en $ config). Daarom moeten we controleren of de map $ config de sleutel van de kaart heeft $ thema's, gebruik dus de functie map-heeft-toets (). Als de sleutel beschikbaar is, doet u het volgende; werp anders een foutmelding in om de ontwikkelaar op de hoogte te stellen.
// _m-buttons.scss // 2.Base .m-knop @each $ key, $ value in $ themes @if map-has-key ($ config, $ key) . # $ value & background: setStyle ($ config, $ key, background); kleur: setStyle ($ config, $ key, color); @else @warn "De sleutel '# $ key is niet gedefinieerd in de map $ config'"
Na alle geschreven code, laten we eens kijken naar het resultaat. Het is fantastisch dat het configuratiegebied gescheiden is van de logica van de module.
.theme-light .m-button background: # f2f2f2; kleur: # 000; .theme-dark .m-button background: # 666; kleur: #fff;
Eindelijk is het tijd om het zelf uit te proberen. Misschien werkt deze oplossing niet voor u en heeft u een andere oplossing nodig, maar al met al hoop ik dat het u zal helpen om uw code goed te houden. Je kunt met dit voorbeeld spelen op Codepen:
In mijn ogen was Sass Maps de beste functie die in Sass 3.3 moest worden geïntroduceerd. Persoonlijk vind ik dat ze een geweldige manier zijn om je stichting een betere structuur te geven en kleine configuratiegebieden te creëren. Sass-kaarten maken het gemakkelijker om waarden te hanteren en te veranderen zonder de logica van de hele codebase te beïnvloeden. Begin ze vandaag nog te gebruiken, uw collega's zullen u dankbaar zijn!
Als u al Sass-kaarten gebruikt, laat ons dan weten hoe u ze in uw projecten gebruikt!
