Ursprungligen skrivet av Uri Kutner på "Bits and Pieces"
Kan du skriva kod som är både återanvändbar och tillräckligt specifik för en vacker design?
Det här mönstret försöker lösa ett svårt problem med kodning:hur gör man kod som är generisk och stabil, men samtidigt utbytbar och specifik?
Återanvändbar specifik kod
I ett uppifrån och ned-tillvägagångssätt börjar man med ett resultat i åtanke och upprepar snabbt koden tills den ger önskat resultat. Du kanske känner till detta som Testdriven utveckling, men det fungerar likadant med dig som testare.
En knapp från Bits återanvändbara komponenters plattform
Ganska okomplicerat. Knappen är en enkel komponent med en kant, kantradie och en färg. Du kan till och med ge den en liten transformation så att den reagerar när du klickar på den.
Så långt har det gått bra.
Utan att veta om knappen behövs en annan knapp i en annan del av koden. En som är djärvare, fylligare och mer passande för att rikta användarens uppmärksamhet till vad du vill just då.
Den har en lila bakgrund, ingen kant och vit text.
Hur gör man en ny knapp?
Alternativ 0:Skapa en ny knapp från början
Ja det här är en grej. Utvecklare uppfinner hjulet på nytt dagligen. Några av mina bästa vänner är döda Dependency Injection-ramverk som folk bara måste skriva för sig själva.
Anpassad specifik kod är lätt att skräddarsy och passar de flesta hörn enkelt. Det förenklar till och med hela din kodbas genom att ta itu med en del av tillvaron helt själv.
Naturligtvis betyder det också att du måste uppdatera den manuellt för varje enkel bugg i buttonshpere. Lycka till med det.
Alternativ 1:Åsidosätt användning av stilar
Eftersom vår knapp får ett klassnamn kan vi enkelt åsidosätta de stilar vi vill ha och få det resultat vi ville ha.
Den här metoden är dock felaktig - den nya knappen får fortfarande alla basstilar från den ursprungliga knappen, så den kommer också att ärva sina framtida ändringar. Till exempel, när vi gör den ursprungliga knappen fetstil, skulle den nya knappen också få denna stil.
För att hålla den nya knappen konsekvent måste vi granska den och åsidosätta de nya stilarna. Detta kan vara tidskrävande och till och med svårt med vissa stilar.
Detta bryter mot Open Close-principen. Komponenten är öppen för tillägg, men den är definitivt inte stängd för modifieringar. Sådana kränkningar av den rena basklassen kan ibland vara värre än du förväntar dig:
jaj! Jag har inte ens redigerat det här, det var så när jag hittade det
Alternativ 2:sätt en flagga på den
UI-komponenter är i grunden funktioner. Du kan skicka parametrar och skapa logik kring det. Detta är strukturen i JSX, men den skulle kunna fungera lika bra i andra format.
<Button invert={true} onClick={ () => this.handleCatGifs()}/>
Det är vettigt vid första anblicken, tills du inser att det bryter mot principen om inversion av kontroll. Du skulle bli instängd i ett underhållshelvete riktigt snabbt.
vah.. byta fall någon?
Och tro mig, det är ännu värre om du har en bugg som bara påverkar vissa knappar och inte andra.
Hur tacklar man då denna fråga?
Ange vanilj- och smaksättningsmönstret 🍨🍨🍦
Skapa en "basklass" som heter Vanilla. Denna bas rymmer all generisk funktionalitet. Du kan lägga in vad som helst där, så länge som någon logik och jämna stilar alltid måste gälla, i alla situationer.
Skapa en ny dekorationssmak för varje ny instans av utseende. Smaker kanske inte ens beror direkt på vaniljen, bara ge deras stilar.
Helst bör du skapa en smak som matchar varje stil i din stilguide.
Håll dina smaker så fysiskt (eller foldmässigt) nära den ursprungliga vaniljbasen. När det ändras, vill du se till att de anpassar sig perfekt.
När du vill ändra utseendet på ett visst element, ersätt det med en annan smak. Alla utseenden måste har sin egen smak! Rouge stilar är svåra att hålla reda på, och de indikerar att du glider bort från din stilguide.
När Smaker inte längre används, ta bort dem! (...eller förvara dem i ett arkiv, om du blir nostalgisk). Helst, när stilguiden fasar ut ett tema, bör kodmotsvarigheten för detta tema också utfasas.
Och det är allt. Vanilj blir bättre och nya smaker kommer ut varje månad. Det är en underbar tid att vara en knapp!
Vad fick vi?
En väletablerad kärna som ansvarar för komponentens passform och funktion.
Ett billigt dekorationslager tillverkat av många återanvändbara varianter, ansvarigt för komponentens form.
Du kan till och med lägga till nytt beteende och animationer till Vanilla senare!
har du någonsin tänkt på att klicka på returnera ett löfte?
I en bredare lins...
Kan din kod gynnas av vanilj- och smakmönstret? Kan du redan ha använt det utan en smakmetafor? Låt mig veta vad du tycker i kommentarerna nedan.
Relevanta tips:
-
Ge aldrig vanilj några stilar! speciellt storlekar (marginaler, stoppningar, positionering), färg (teckensnitt, ram, bakgrund, skugga), typsnitt, dekorationer.
-
Ge din smak ett meningsfullt och specifikt namn. Fokusera på deras syfte och tänk på att de skulle ersättas av mycket liknande smaker, så var inte för abstrakt.
På Bit prefixar vi smaker med det nuvarande designsystemet. Det ser ut som neonskyltar just nu så vi kallar dem neonknappar. -
Var modig. Gör en kodgaffel av din Vanilla och starta en ny basklass med ny, spännande och annorlunda funktionalitet.
-
Komponera stilar tillsammans genom att skicka smaksatta instanser tillsammans. t.ex. skulle en vaniljbekräftelsemodal använda en vaniljknapp, men NeonConfirmationModal skulle skicka stilar och NeonButton till sin Vanilla.
Det var allt tills vidare. Tack för att du läser, och kommentera gärna och fråga vad som helst! Jag chattar gärna :)