– Ikke lag komponenter for komponentenes skyld
– Når vi bygger designsystem, bør vi stille et enkelt spørsmål før vi lager en ny komponent: Kan dette løses enklere med det webstandarden allerede gir oss, skriver Designsystemet-teamet.
Frontend-verden elsker nye verktøy. Nye rammeverk, nye biblioteker, nye måter å pakke inn det som egentlig bare er HTML, CSS og litt JavaScript.
Akkurat nå er det webkomponenter som får mye oppmerksomhet, av gode grunner.
Men vi må passe oss for en klassisk felle: å bruke teknologien fordi vi kan, ikke fordi vi bør.
Rammeverkuavhengighet er målet
I Designsystemet har vi ett overordnet mål: Det skal kunne brukes uavhengig av teknisk rammeverk.
Designsystemet brukes av hundrevis av digitale løsninger, både i offentlig og privat sektor. Det er også et digitalt fellesgode gjennom FN-initiativet Digital Public Goods Alliance, og kan brukes fritt internasjonalt.
Da holder det ikke å lage komponenter som bare fungerer godt i ett økosystem. De må fungere for løsninger bygget i React, Vue, Angular og mye annet. Og i løsninger som skal leve lenge.
Webkomponenter trekkes ofte frem som løsningen på dette. De fungerer på tvers av rammeverk og kan i teorien gi oss én implementasjon for alle. Det høres fristende ut, men det betyr ikke at alt bør være en webkomponent.
Webstandarden gir oss mer enn vi tror
En knapp er ikke bare en knapp. Når du bruker < button > i HTML, får du med deg mye gratis: tastaturnavigasjon, fokushåndtering, semantikk og støtte i skjermlesere.
Bygger du din egen knapp som webkomponent, må du enten gjenskape alt dette selv, eller bygge videre på en < button > med JavaScript “under panseret”. Begge deler har en kostnad: mer kompleksitet, potensielle utfordringer for skjermlesere og kode som blir vanskeligere å forstå.
Det samme gjelder mange andre komponenter. Radioknapper, inputfelt og feltgrupper er problemer webstandarden allerede har løst for oss.
Når vi erstatter det med JavaScript, bytter vi ut noe robust med noe vi må vedlikeholde selv.
Det betyr ikke at webstandardene alltid er perfekte i praksis. Selv om nettleserstøtten er god, finnes det fortsatt hull – både i tilgjengelighet og i generell funksjonalitet.
Skjermlesere og annen hjelpemiddelteknologi henger ofte etter, og samtidig er ikke alle nye plattformfunksjoner godt nok støttet på tvers av nettlesere.
Derfor kan det være nødvendig å bygge videre på standardene, enten ved å forbedre tilgjengelighet eller ved å bruke JavaScript der plattformen ikke strekker til ennå.
Mindre JavaScript gir bedre løsninger
Hver gang vi velger en webkomponent, velger vi også JavaScript som en forutsetning.
Det påvirker ytelse, robusthet, lastetid og hva som skjer når JavaScript feiler.
I Designsystemet prøver vi å snu dette: HTML og CSS først, JavaScript bare der det faktisk trengs.
Moderne webstandarder gir oss langt mer enn før. Funksjonalitet som tidligere krevde JavaScript eller kompilering, kan nå ofte løses med native web-API-er som Popover API og Invoker Commands API, eller med nye CSS-muligheter som @layers og relative selectorer (f.eks. :has).
Kombinert med smart bruk av klassenavn og data-attributter, kan Designsystemet tilby fullverdige komponenter i nesten utelukkende HTML og CSS.
Resultatet er enklere kode, bedre ytelse og færre ting som kan gå galt.
Eksempel Button:
<button class="ds-button" data-variant="secondary" data-color="danger">Eksempel Popover:
<button
class="ds-button"
type="button"
popovertarget="my-popover"
>Åpne popover</button>
<div class="ds-popover" popover id="my-popover" >
Popoveret gir en rask beskjed. Her kan du vise brukeren informasjon som er relevant for konteksten.
</div>
Ulike behov, ulike valg
Mange som satser tungt på webkomponenter går også all-in på Shadow DOM. Det gir sterk isolasjon, og for store organisasjoner med mange team kan det være helt avgjørende.
Men det kommer med en pris: en ny mental modell for utviklere. Plutselig må du forholde deg til slots, CSS parts og skjult, og ikke minst låst DOM-struktur. Du er ikke lenger tett på plattformen, du er inne i et abstraheringslag.
I Designsystemet har vi valgt å holde oss i light DOM, nettopp for å være så nær HTML som mulig. Det gjør det enklere å forstå, enklere å debugge og enklere å ta i bruk.
Det betyr ikke at andre gjør feil. Organisasjoner med hundrevis av applikasjoner kan ha helt andre behov. De kan prioritere isolasjon, sentral kontroll og muligheten til å oppdatere komponenter på tvers av mange løsninger uten å deploye alt på nytt. Da gir det mening å pakke mer inn i webkomponenter.
Poenget er ikke at én strategi er riktig for alle, men at valgene bør være bevisste.
Til syvende og sist handler dette også om hvem vi bygger for. Et felles designsystem skal kunne brukes av mange, med ulik bakgrunn, ulik kompetanse og ulike behov.
Da er det en fordel å lene seg på det som er universelt: HTML, CSS og grunnleggende webkompetanse. Ikke alle kan, eller vil, sette seg inn i et spesialisert rammeverk eller en avansert komponentmodell. Men de fleste kan forstå en < button > med klassenavn og data-attributt.
Konklusjon
Webkomponenter er et kraftig verktøy – som også Designsystemet benytter og nyter godt av ved behov, men de er ikke et mål i seg selv.
Når vi bygger designsystem, bør vi stille et enkelt spørsmål før vi lager en ny komponent: Kan dette løses enklere med det webstandarden allerede gir oss?
Ofte er svaret ja. Og da er det kanskje nettopp det vi bør gjøre.
Start med standardene, og legg bare til ekstra abstraksjon når det faktisk trengs.
Designsystemet er et åpent samarbeid med et community på Slack som består av folk fra over 230 ulike virksomheter. Her deler designere og utviklere erfaringer, diskuterer løsninger og bidrar til videre utvikling. Vi lærer mye av hverandre. Alt arbeidet foregår åpent på GitHub. Bli med i Slack her.