Dette var uken for Betty White-vitser 👵 , Trump-tilfeldigheter 🤡 og en minneverdig forestilling 🎙. Og 1 804 ting skjedde i frontend-verdenen

<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uken som var.

Lag tilpasningsdyktige komponenter med typesikre as-props

Jeg har lenge vært i heiagjengen for å la de som skal bruke komponentene vi lager, bestemme hva slags HTML-element de skal rendre. Det gjør det enklere å lage universelt utformede løsninger, også lar det deg lage færre spesialtilpassede komponenter. Win win!

Men selv om det kan være relativt rett frem å få til med en prop (ofte kalt as ), kan det være skikkelig vanskelig å få til på en typesikker måte. For en <button /> -tag har andre props enn en <a /> -tag, og om du sender inn en custom komponent, vil du gjerne ha typesikkerhet der også.

Heldigvis har pseudo-navnebror Kristóf P skrevet en veldig fin artikkel som forklarer deg hvordan man gjør det, og hvilke tradeoffs man bør gjøre. Den har en litt “Draw the rest of the owl” følelse når det kommer til TypeScripten, men det får man heller bare tåle. Jeg synes den forklarte det godt i alle fall!

Behind the 'as' prop: polymorphism done well

Ark 3.0.0 er ute!

Jeg har lenge vært godt investert i Chakra UI. Det er rett og slett et bra bibliotek for å lage gode brukergrensesnitt raskt. Men Chakra er bygget på CSS-in-JS rammeverket Emotion, og Emotion sliter litt med å støtte effektiv serverside-rendering. Så da må man tenke litt nytt.

Ark er et “headless” UI-bibliotek, laget av de samme folka som står bak Chakra. Og på mange måter er det en verdig avtager også. De har nå sluppet en versjon 3.0.0 av biblioteket sitt, som gjør det enklere enn noen gang å lage kule brukergrensesnitt. Kanskje det er på tide å bevege seg over fra Chakra til Ark?

Les changeloggen her: https://ark-ui.com/react/docs/overview/changelog

Litt diverse React-nytt

Det var et par mindre React-nyheter som kan være nyttige å få med seg denne uken — enten for å være ekstra interessant i lunsjen, eller bare for å føle deg bedre enn andre når du overrasker dem med intrikat kunnskap det ikke er nødvendig å vite.

🎉 React

React ble open sourcet for 11 år siden forrige uke! Det er veldig, veldig lenge siden for noen, men starten av min karriere i Bekk. Jeg vil argumentere det har gjort underverker for stabiliteten til frontend-utviklingssfæren, selv om vi ikke på noe vis er i mål enda. Hurra for 11-åringen!

React 19 ute i RC

Det som er fint med React, er at det tar ganske lang tid mellom hver breaking change de kommer med. Og når det kommer en breaking change, så får man som regel god tid på å forberede seg. Ulempen er jo at man blir så godt vant at man skvetter litt til hver gang det kommer en faktisk major-versjon.

Så ta dette som siste advarsel — det ser ut til at en faktisk 19.0.0 versjon er rett rundt hjørnet — for nå har React-teamet sluppet hva de selv sier er en release candidate som kommer til å være kliss lik det som slippes i den offisielle releasen.

Om du har lyst til å tyvstarte på oppgraderingsjobben (som visstnok ikke skal være altfor stor), kan du jo egentlig… oppgradere i dag, og se hvordan det går. Lykke til!

Husk å holde react og react-dom i sync

På weben består React av to npm-pakker — react og react-dom . De følger samme versjoneringstall, og lanseres alltid i tospann. Men før var det liksom ikke så farlig om de var helt i sync! Så lenge man var på samme major-versjon, var React helt okei med en liten diff mellom versjonene.

Men nå blir det hardare kår for sloppy avhengigheter. Fra og med v19 vil React kaste en feilmelding om de to versjonene ikke er helt i sync. Det vil si, er man på 19.0.1 på react , må man være på nøyaktig 19.0.1 på react-dom også. Or suffer the consequences 😱

Les mer i pull requestet her: https://github.com/facebook/react/pull/29236

Det… var faktisk det jeg hadde for dere denne uken. Takk for at dere leste, og velkommen tilbake til neste ukes ForrigeUke (denne uken?). Tjohei!

ForrigeUke (uke 22, 2024) was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Så du vil bli en produktleder? Eller kanskje du har fått rollen i fanget, fordi organisasjonen din har blitt delt opp i produktområder eller noe annet nymotens? Lurer du på hvorfor folk plutselig har begynt å skrive OST med store bokstaver?

Produktledelse er et utrolig spennende fag, som bare blir mer og mer interessant å både jobbe med og lære om. Men det er mye stammespråk, mye teori og mye… greier man bør sette seg inn i, og det kan være en ganske overveldende opplevelse å bli kastet inn i. Så hvor skal man egentlig starte, om man ikke har jobbet så mye med det før?

Heldigvis for oss, er det utrolig mange velskrevne bøker om produktledelse. Denne artikkelen gir deg et utgangspunkt til hvilke bøker du burde komme deg gjennom frem mot sommeren, og hvorfor jeg anbefaler nettopp de bøkene.

Inspired

Av Marty Cagan

Denne boken er nok den mest nevnte boken på LinkedIn for tiden. Og ikke uten grunn. Marty Cagan sitt klassiske verk Inspired er en real innføring i produktledelse og ikke minst verdien i å innføre produktteam over utviklingsteam eller feature team.

Selv om boken kom ut i 2008 (og re-utgitt i 2017), er det plenty av gode tips og triks som de aller fleste organisasjoner her i Norge har veldig godt av å høre i dag. Boken er stappfull av pragmatiske og praktiske eksempler på hvordan store tech-selskaper klarer å innovere og bevege seg fremover flere ganger raskere enn andre — og hvorfor noen selskaper rett og slett ikke får det til.

Det er mange gode poenger som kommer frem i boken. Det å fokusere på outcomes over outputs er en av dem, og det å jobbe faktisk smidig, er to gode eksempler på det. Den er nok mest relevant for produktledere (eller folk som ønsker å være det en dag), men er nok nyttig lesning for alle som jobber i produktteams også.

Du kan kjøpe boken her. Og når du først er i gang, kan jeg også anbefale Empowered — en slags oppfølger som har et litt bredere nedslagsfelt, og handler mer om hva hele team må gjøre for å oppnå idealene i Inspired.

Continuous Discovery Habits

Av Teresa Torres

Denne boken er en av de nyttigste bøkene jeg har lest i år. Teresa Torres argumenterer sterkt for å innhente brukerinnsikt hele tiden, gjennom smarte verktøy og gode teknikker. Hun argumenterer sterkt for å undersøke mulighetsrommet man har for å løse utfordringer brukerne har, og verifisere antagelsene sine før man begynner å implementere noe som helst. Mesteparten av arbeidet bør med andre ord skje lenge før utviklerfingre treffer tastatur.

Torres introduserer også en teknikk hun kaller — litt morsomt på norsk — OST, eller Opportunity Solutiton Trees. Denne teknikken går ut på å utforske hvilke muligheter man har for å løse ett eller annet forretningsmål, dele dem opp i under-muligheter, og til slutt utforske en rekke forskjellige løsninger på disse. Det er en skikkelig kraftig teknikk, som vi har begynt å bruke flittig i vårt produktteam. Runar skrev også en veldig fin introduksjon til denne teknikken her om dagen, som definitivt kan anbefales.

Dette er nok en bok som argumenterer sterkt for å jobbe smidig — ikke bare i teorien, men i praksis. Torres argumenterer også for å blande “discovery” og “delivery” fasene mye tettere enn andre forfattere har gjort.

Du kan kjøpe boken her.

Team Topologies

Av Matthew Skelton, Manel Pais

Når man jobber i større organisasjoner, er teamene man jobber i — og hvordan de er strukturert — noe man kontinuerlig itererer på. Hvordan man splitter opp ressursene sine er definitivt en av de tingene man gjør som påvirker både flyt, produktivitet og gjennomføringsevne mest i en produktorganisasjon.

Boken “Team Topologies” av Matthew Skelton og Manel Pais har blitt et slags standardverk for de som tar for seg denne jobben. Erfaringsmessig er dette et samarbeid mellom avdelingsledelsen og produktlederne.

Team Topologies argumenterer for at man burde strukturere teamene i fire distinkte typer — strøm-følgende, muliggjørende, kompliserte undersystem og plattform-teams. Når man deler seg inn i disse topologiene, mener forfatterne at man klarer å minimere kognitiv last, tilpasse seg endringer i organisasjonen og ha fokus på å levere.

Vi har brukt teorien fra denne boken i praksis hos flere kunder, og har opplevd at det også fungerer i praksis. Egentlig ganske gøy!

Du kan kjøpe boken her.

Accelerate

Av Nicole Forsgren, Jez Humble, Gene Kim

“Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations” (jadda, de er glade i lange boknavn disse amerikanerne) er en av de første store bøkene jeg leste som teknolog, og det er kanskje det mest klassiske verket innen smidig produktutvikling. Om du skal være produktleder, tror jeg rett og slett du MÅ ha lest denne boken før du setter i gang.

Boken foreslår fire nøkkelmetrikker man bør se på for å bli en skikkelig bra digital produktorganisasjon:

• Hvor ofte du deployer til produksjon
• Hvor fort det går fra du skriver kode til det er i produksjon
• Hvor fort man kan rette feil i produksjon
• Hvor ofte man brekker produksjon

Mye om produksjon, da, med andre ord.

Boken lener seg tungt på forskning og erfaring fra store teknologiorganisasjoner, og har muligens flere referanser enn noe annet verk jeg har lest. Utrolig gøyal lesning — om enn litt… tung til tider.

Du kan kjøpe boken her.

Measure What Matters

Av John Doerr

Du har hørt om OKR. Du har gjort OKR. Du har ikke helt fått til OKR. Og det er helt greit. Noen mener til og med at det er din egen skyld.

En kollega av meg sa en gang at OKR et et “litt for enkelt rammeverk for å oppnå noe som er utrolig vanskelig”. Og det er kan jeg ikke være mer enig i. Men da kan det også være veldig greit å lese litt om hvordan det egentlig skal gjøres!

“Measure What Matters” er en fantastisk bok som tar deg med inn i OKR-verdenen, og hva man egentlig prøver å løse. Og det er jo litt som tittelen nevner — at man skal prøve å måle hva man egentlig prøver å få til. Det å prioritere er vanskelig på alle plan, men om man skal klare å sette mål for en hel organisasjon, så bør man virkelig sette seg inn i materien.

Denne boken er en “must-read” (har man et norsk uttrykk for det egentlig?) for alle som vil jobbe målrettet — og spesielt alle som har fått beskjed om at “nå skal vi bruke OKR” for å oppnå noe som helst.

Du kan kjøpe boken her — og hadde jeg vært deg, hadde jeg plukket med meg Radical Focus i samme slengen. Begge disse bøkene er helt ekte gullgruver for deg som vil prøve å få folk til å dra i samme retning.

Escaping the Build Trap

Av Melissa Perri

Vi er jo alle glade i å lage ting. Ingenting ser bedre ut på ukesoppsummeringen enn å ha lansert en ny tjeneste, en ny feature eller på andre måter å ha tilbudt brukerne deres noe mer. Men stopper du noen gang opp for å tenke om det var det de faktisk trengte?

“Escaping the Build Trap: How Effective Product Management Creates Real Value” introduserer konseptet om bygge-fella — det å lage ting bare for å lage ting, uten å verifisere at det er ting folk faktisk kommer til å bruke. Jeg har i alle fall gått i den fella opptil flere ganger selv!

For å fikse dette foreslår Perry et par forskjellige teknikker — men den som skinner best gjennom er å fokusere mer på “outcome” (hva folk faktisk sitter igjen med av verdi) enn output (hva du har laget). Dette er ganske likt det du hører fra både Inspired og Accelerate, men har muligens et ekstra fokus på sluttbrukerne.

En veldig bra bok i alle fall — og en jeg vurderer å lese en gang til i 2024.

Du kan kjøpe boken her.

Bedre Produkter

Av Ida Aalen

Helt til slutt vil jeg komme meg min kanskje aller største anbefaling. Om du jobber med produktutvikling i Norge, er dette boken du burde lese først av alle.

Ida Aalen har en fantastisk evne til å oppsummere produktleder-kunnskapen som finnes i alle bøkene jeg har nevnt ovenfor (og et par til) — og oversette det til norske forhold. Alle er ikke Spotify eller Meta — og det er en god del tilpasninger man burde gjøre underveis i arbeidet sitt for å få ting til å fly her i Norge.

“Bedre Produkter” er proppfull av erfaringer fra forskjellige organisasjoner her i landet, og tar for seg hvordan beste praksis kan se ut når man jobber i norske forhold. Om jeg skulle lest én bok i år, så hadde det definitivt vært denne. Og så hadde den inspirert meg til å lese resten på denne listen.

Du kan kjøpe boken her. Og det, det synes jeg du skal gjøre.

Mye å lese

Om du føler deg litt overveldet, så er det helt okei. Det hadde jeg også gjort. Men alle som en er fantastiske ressurser for å få deg bedre rigget som produktleder der du jobber.

På tvers av alle disse bøkene, så er det en slags konsensus om å spørre brukerne, iterere raskt på feedback og utforske mulighetsrommet man har. Og det er dritvanskelig. Men — herre min hatt, som det er verdt det.

Jeg håper du blir inspirert til å plukke opp et par bøker i 2024, og utvikle deg både som produktleder og medarbeider. For det har aldri vært et bedre tilbud for folk som vil mer.

Og du — hvis du har småbarn, en stressende hverdag, eller bare ikke er så flink til å lese, så kan jeg på det varmeste anbefale å signe opp for en lydboktjeneste. Jeg har hørt haugevis av bøker på vei til og fra jobb på Audible — og det er en flott måte å bygge kompetanse på, uten at det stjeler noe av fritiden din på.

Lykke til!

Leseliste for produktledere was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bekk jobber med noen av de største og viktigste premissgiverne når det kommer til teknologi i Norge. Men hva slags teknologi er det egentlig vi bruker? Og hva synes vi egentlig om det? Vi har gjennomført en unik intern spørreundersøkelse for å finne ut av nettopp det.

Hva er dette for noe?

Frontend-miljøet har alltid beveget seg fort – og kanskje spesielt fort det siste tiåret. Det er det mange grunner til. Brukere forventer mer av frontend-løsningene vi lager, og på grunn av det har det vært enorme investeringer i både forskning og nyutvikling av verktøyene som lar oss shippe bedre brukeropplevelser raskere. Mobiltelefonene og datamaskinene våre har blitt kraftigere, og mulighetsrommet vi har, har også vokst dramatisk.

Så da er det kanskje ikke så rart da, at folk opplever det som har blitt omtalt som “frontend fatigue”. For i prosessen med å lage bedre verktøy, har man prøvd utallige forskjellige måter å løse det samme problemet på – nemlig det å lage gode brukeroppleveser på en rask og enkel måte. Og da blir det nødvendigvis en god del iterasjon. Og slitne frontendere.

Men hva er egentlig situasjonen i dag? Hva er det folk bruker, og hva synes de om status quo? Det har vi egentlig ikke så veldig mange tall på. Vi har State of JS-undersøkelsen, men den har en stor vekting mot det amerikanske markedet, og er ikke direkte overførbar til hva vi opplever her på berget. Og der – der fikk vi en idé.

Bekk er et ganske stort konsulentselskap, med folk hos et bredt spektrum av Norges IT-bedrifter. Vi er representert hos både store offentlige aktører, mellomstore halv-statlige bedrifter og mindre startups. Vi er en gjeng med både unge og erfarne, som jobber både med hippe greenfield-prosjekter og tyngre forvaltningsoppdrag. Vi har rett og slett en unik innsikt i hva frontendere og fullstackere bruker! Og den — den har vi samlet inn, og vil dele med dere nå.

Metode og demografi

For å samle inn denne innsikten, laget vi en enkel spørreundersøkelse med 22 spørsmål, som vi tror de fleste som jobber med framsia vil finne interessant. Vi sendte ut en god gammeldags coco@channel på #frontend-kanalen vår på Slack, og ba alle som jobber med frontend – om det er litt eller mye — om å dele sine erfaringer.

Vi samlet inn meningene til 98 forskjellige frontendere og fullstackere i Bekk. Respondentene jobbet hos over 30 forskjellige kunder, og har nok i sum jobbet med langt over dobbelt så mange opp gjennom karrieren sin. Alle spørsmålene ble besvart av samtlige deltakere, som selvfølgelig svarte anonymt, og med en oppfordring om å dele sine ærlige meninger og erfaringer. De aller fleste spørsmålene var multiple choice (kanskje du er på et team som forvalter både ny React-kode og gammel Angular-kode?), og mange spørsmål hadde både en “hva bruker du”-seksjon og en “og hva synes du om det”-seksjon.

Kanskje du kan relatere til det vi har funnet, eller kanskje du er skikkelig uenig. Men en god debatt vil det nok starte uansett. Og debatt er bra.

Bekkerne som svarte på denne undersøkelsen fordelte seg utover en relativt representabel del av demografien vår. I underkant av 38 % var ganske ferske i gamet, 28 % var seniorkonsulenter, 17 % var managere og 17 % til var det man kan kalle ringrever.

Folka jobbet også i ganske forskjellige teams. Ca 2 av 3 jobbet i relativt store teams på over 6 medlemmer, mens den siste tredjedelen hadde en litt mer intim arbeidshverdag på teams mellom 1 og 6. Veldig få av oss jobbet alene, eller med én eller to til.

Disse grupperingene inkluderer alt fra utviklere og designere til produktledere, testere og jurister. Det er kanskje derfor ikke så rart at det ikke er så mange som jobber på egenhånd.

Så nå vet dere hvordan vi gjennomførte undersøkelsen, og litt om hvem som svarte på det. Men hva var det de egentlig svarte på – og hva var resultatene? La oss hoppe i det!

Hvilke JavaScript-biblioteker bruker du på oppdraget ditt i dag?

Det aller første vi spurte om var nok det mange av oss lurer mest på. Hva er det folk bruker til å lage interaktive frontend-apper i dag?

Resultatet var overraskende ensidig. Hele 83.7 % av respondentene forteller at de skriver React-kode på en daglig basis (86.8 % om du inkluderer React Native). 10.2 % bruker Vue, 7.1 % bruker Elm og 3.1 % bruker Angular.

Det var også noen litt overraskende lave tall i undersøkelsen. Aller mest overraskende var nok at det var ingen Bekkere som bruker Svelte på arbeidsplassen sin! Det er mange som snakker positivt om Svelte internt, og mange som nevnte at de gjerne skulle jobbet med det – men det er altså ingen som bruker det i produksjon i dag.

Begrunnelsene for disse valgene var mange, men i hovedtrekk kan man oppsummere Reacts dominans slik:

Enkel tilgang på ressurser

Mange av kundene til Bekk er store organisasjoner, som trenger tilgang til mange ressurser for å få gjort arbeidet sitt godt og effektivt. Og er det noe som er enkelt å skaffe til veie for tiden, så er det folk som kan React.

Det er nok mange grunner til det, men det vi ser er at det er veldig mye gode læringsmuligheter når det kommer til React. Vi har både egenutviklede workshops, forskjellige faggrupper og programmer, og masse folk som er genuint interessert i å bli gode, raskt. React har god dokumentasjon, det er massevis av opplæringsprogrammer man kan kjøpe seg, og biblioteket er i stadig utvikling. Kanskje ikke så rart da, at vi ser at flere av kundene våre har valgt React som standard-måten å utvikle løsninger på.

(Veldig) modent

React er 11 år gammelt i dag, og selv om dagens kode ikke nødvendigvis ser ut som den vi skrev for et tiår siden, er konseptene godt forankret og alle edge cases godt dekket. Mange fremhevet også at utvikleropplevelsen var ekstremt god, og at det er et enormt økosystem av biblioteker og meta-rammeverk som gjør det enkelt å shippe kode til produksjon som bare funker.

“Learn once, write anywhere”

Vi ser også at det er mange som fremhever at det å “kunne React” gjør at man ikke bare er frontendutvikler, men også mobilutvikler. Mange av kundene våre har React Native-applikasjoner, og når man jobber med både vanlige frontend-apper og mobilapper, så er det enklere å hoppe mellom paradigmene.

Hvilke rammeverk bruker du på oppdraget ditt i dag?

Som utvikler, har vi lenge sett at rammeverk er gode å ha når en teknologi blir mer og mer kapabel. Vi har merket dette lenge på backenden, med både Spring Boot, Ktor og .net Core som klare favoritter – men i de siste årene har såkalte meta-rammeverk for frontend-apper også blitt veldig populære.

Det var derfor litt overraskende å se at hele 63 % av respondentene meldte at de ikke bruker noe meta-rammeverk for å lage frontend-appene sine. Ca en tredjedel brukte Next.js (enten i “gammel” eller “ny” versjon), mens kun 6 % brukte Remix, og 3 % brukte Nuxt.

Det er nok ofte enkelt å se seg blind på den globale diskursen når det kommer til teknologivalg. For det å dra inn et metarammeverk som Next.js eller Remix er nemlig ikke trivielt i en rigg som ofte har en fast hosting-leverandør, eller manglende støtte for Node-apper. Ofte er det heller ikke ønskelig med den økende kompleksiteten det fører med seg å ha en app som rendrer ting på serversiden. Det er mange saksbehandler-applikasjoner der ute, og både SEO og tid til man ser noe på skjermen etter en sidelast er ikke så viktig når man har en intern brukergruppe på noen titalls eller hundretalls saksbehandlere som laster appen din hver morgen kl 0900.

Vi ser allikevel en stor økning i bruken av meta-rammeverk rundt om. Rent anekdotisk merker vi at antallet utviklere som bruker enten Next.js eller Remix har økt betraktelig det siste året. Kanskje utvikleropplevelsen en slik løsning gir, etterhvert vil være verdt den ekstra kompleksiteten? Kanskje det å eliminere konsepter som backend-for-frontends gjør det ekstra interessant å migrere seg over? Vi er veldig spent på hvordan denne statistikken kommer til å utvikle seg år etter år.

Det skal også nevnes at ingen sa de brukte hverken SvelteKit eller Astro i produksjon i dag. Det er kanskje ikke så rart når det kommer til førstnevnte (siden ingen brukte Svelte), men at ingen bruker Astro (som har fått veldig mye positiv omtale i det siste, og som er kompatibelt med React), var mer overraskende.

Hva bruker du for tilstandshåndtering?

Tilstandshåndtering har lenge vært en av de vanskeligste tingene vi frontend-utviklere har å bryne oss på. Og det er kanskje her vi har iterert de siste 10 årene også.

Omtrentlig 50 % bruker Reacts innebygde primitiver for tilstandshåndtering, nemlig useState, useReducer og useContext. Ca en tredjedel bruker mer moderne respons-cache hooks som useSWR eller TanStack Query, 7 % bruker det nå forlatte Recoil, mens 14 % fortsatt bruker Redux.

Erfaringene vi hentet inn hadde noen hovedpoenger:

Redux er klønete og føles gammeldags

De som jobbet med Redux, var mildt sagt ikke fornøyd. Det ble uten unntak brukt i eldre kodebaser, og samtlige respondenter ønsket å skrive seg vekk fra det. Selv om Redux har blitt veldig mye bedre i det siste, oppleves det fortsatt som en unødvendig runddans, som gjør det vanskeligere å forstå eksisterende kode, eller å utvikle nye features.

Det meste løses av primitiver (og noen smarte hooks)

Over halvparten av respondentene sa de brukte Reacts Context API og useState / useReducer til å håndtere tilstand i applikasjonene sine. Det er jo et tegn på at primitivene som tilbys løser de aller fleste behov, og at det ofte ikke er vits å implementere en mer ambisiøs løsning i de appene vi lager.

En av fordelene med denne trenden er at det er mindre APIer og biblioteker å lære seg. Klarer man seg med det mest grunnleggende – hva er egentlig vitsen i å dra inn nok et abstraksjonslag?

Vi så også en stor andel utviklere som var fornøyde med biblioteker som abstraherer vekk henting og mellomlagring av responser fra serveren, som useSWR og TanStack Query. Mange nevnte at dette ikke er tilstand i ordets rette forstand, men heller en måte å cache data fra serveren på. Og om man tenker slik på det, så kan det jo være

Meta-rammeverkene tar over

En annen trend vi så er at folk forvalter mindre tilstand enn før – i stor grad grunnet metarammeverk som Next.js og Remix. Når man knytter server og klient tettere sammen, blir det nemlig mindre tilstand å håndtere. Caching av data på klienten blir abstrahert vekk, og man blir i større grad oppfordet til å putte tilstand i URLer, eller i såkalte nøstede ruter. Og da er det ikke så mye tilstand igjen å håndtere egentlig.

Typesetting — hva bruker du?

Dette spørsmålet førte til nok en overraskelse – nemlig hvor populært TypeScript har blitt! Hele 81.6 % av de som svarte oppga at de utelukkende brukte TypeScript i kodebasen sin, og kun 3.1 % sa at de hadde rene JavaScript kodebaser. 9.2 % svarte at de brukte andre typesikre språk som Elm eller Dart.

Denne endringen i hvordan vi skriver kode har nok hatt en enorm påvirkning på to ting – mengden bugs brukerne våre snubler over, og mengden enhetstester vi skriver for frontend-koden vår. For hvorfor skrive tester for ting vi kan statisk analysere oss frem til?

Hvilke verktøy bruker du til testing?

Apropos testing – vi avdekket mer spennende innsikt når det kom til hvordan vi tester frontend-koden vår.

Når det kommer til enhetstester, så ser vi at 30.6 % bruker Jest, mens 21.4 % bruker Vitest. Ende-til-ende-testene ble skrevet i Cypress i 27.6 % av tilfellene, mens 24.5 % sverget til Microsofts Playwright. Og litt over en fjerdedel av oss skriver ikke frontend-tester overhodet.

Tilbakemeldingene rundt testing var at de som skrev tester var ganske fornøyd med hvordan verktøyene var for tiden. Både Jest, Vitest, Cypress og Playwright er moderne rammeverk, som gjør det enkelt å automatisere det man tidligere trykket seg gjennom etter en prodsetting for å sjekke.

Det var overraskende å se at en fjerdedel ikke skriver tester for frontend-koden sin i det hele tatt – men etter å ha analysert tilbakemeldingene litt, ser vi at det har en forklaring det og. Typesystemer tar for seg mesteparten av behovet man historisk sett hadde for tester på frontend-apper, og bedre monitorering og bedre tilgang til å deploye til produksjon gjør at man kan finne og fikse bugs raskere når de en gang skjer.

Det er definitivt fortsatt gode bruksområder for testing, og vi anbefaler de fleste å innføre enkle tester som verifiserer at løsningene vi utvikler fungerer uten problemer. Det kan man nå få til med ende-til-ende-testverktøyene vi har listet opp over. Man kan også bruke disse verktøyene til å teste ganske mange edgecases når det kommer til universell utforming. Allikevel kan det å skrive tester utover dette være en høyere forvaltningsbelastning enn det er verdt for mange.

Hvilke teknologier bruker dere til styling?

Når man tenker på frontend, er det mange som trekker direkte paralleller til CSS. For hva er det folk egentlig bruker der ute?

Resultatene fra spørsmålet vårt var ganske splittet. Det var ca 1/4 hver som brukte enten helt vanlig CSS, SCSS, (S)CSS Modules og Styled Components. 15 % brukte Tailwind, 9 % brukte Less, og 8 % brukte Styled System.

Tilbakemeldingene var like delt. Noen elsket Tailwind, mens andre hatet det. Noen sverget til CSS-in-JS, mens andre synes det var både pest og kolera på samme tid. Men de aller fleste virket ganske fornøyde med de teknologivalgene de hadde tatt.

Det kan nok tenkes at styling har blitt en god del enklere å jobbe med etterhvert som nettleserne vi jobber med har begynt å oppdatere seg selv. Det er lenge siden man måtte kjøre opp Internet Explorer i en virtuell maskin for å sjekke at alt så bra ut. Dette er en flott utvikling, som gjør at vi kan bruke mer av tiden vår på å lage brukerverdi for alle, og mindre tid på å knote med forskjeller mellom nettlesere.

Bruker dere et designsystem?

Det har blitt populært å bruke designsystemer, gitt!

61.2 % av respondentene sa de brukte et egenutviklet designsystem, 20.4 % sa de brukte et designsystem basert på et komponentbibliotek som Chakra UI eller Material UI, mens kun 18.4 % sa de ikke brukte et.

Det er interessant å se hvor mange av oss som jobber med egenutviklede designsystemer og komponentbiblioteker. Det gir oss en enorm fleksibilitet, men også en veldig stor forvaltningsbyrde. For hvor stor forskjell er det egentlig mellom knappene hos Tolletaten og NAV? Eller hvor annerledes er brukerbehovene til en datovelger hos Vy enn hos SpareBank 1?

Det er kanskje ikke så rart at vi ser initiativer som Digitaliseringsdirektoratets nasjonale designsystem for offentlige virksomheter, eller (det litt mer ekstreme) Brad Frost sitt forslag om et globalt designsystem. Vi håper vi ser en større standardisering rundt dette fremover – som vil være en enorm seier både for brukeropplevelse, utvikleropplevelse, universell utforming og produktivitet for utviklere generelt.

Hvordan gjør dere bygging av JavaScript?

Der frontendene for 10 år siden var relativt statiske og frie for kompilering, har vi lenge merket en tendens til at det kreves stadig mer preprosessering av frontend-koden vår før vi kan servere den til sluttbrukerne. Og også her har det skjedd en enorm utvikling de siste par årene.

Resultatene viser at 41.2 % bruker Vite til å bygge applikasjonene sine, 30.0 % bruker Webpack, og 24.7 % lener seg på rammeverket sitt for å gjøre denne jobben. 5.2 % brukte Parcel, mens bare 2.1 % brukte frontend-verdenens nye superhelt Bun.

Migrasjonen vekk fra Webpack ser ut til å være i full gang. Der det en gang var en skrekkoppgave å sette seg inn i det nye prosjektet sitt sin Webpack-config, ser vi nå at mye av denne kompleksiteten abstraheres vekk gjennom verktøy som blant annet Vite. Meta-rammeverkene tar også over en stadig større del av denne jobben – som tross alt kan løses på en generell måte.

Vite har seilet opp som en stor favoritt blant prosjektene vi jobber på. Det er noen som bruker alternativer som Parcel eller Bun, men i stor grad ser det ut til at Vite er markedsvinneren her. Og det er kanskje ikke så rart, gitt hvor raskt og greit det er å bruke?

Hvordan ser backendene dine ut?

Selv om dette er en frontend-undersøkelse, så er de aller fleste av oss fullstack-utviklere. Og hva er det egentlig som sender oss all den dataen vi jobber så hardt med å gjøre om til gode brukeropplevelser?

I Bekk er i alle fall fasit at omtrentlig 57 % av alle backends er basert på enten Kotlin, Java eller Scala – og i hovedsak Kotlin. 24.5 % henter dataen sin fra .net-baserte servere, mens kun 6.1 % bruker Node. Like mange bruker meta-rammerverket sitt som sin eneste backend.

Vi jobber med mange tunge systemer, med stort behov for avanserte sikkerhets- og integrasjonsmuligheter. Så da er det kanskje ikke så rart av nesten tre fjerdedeler av oss integrerer med “gode gamle” teknologier som JVMen eller .net. Det blir allikevel interessant å se hvordan dette tallet utvikler seg i fremtiden, etterhvert som metarammeverkenes fremmarsj muliggjør stadig enklere feedback-løkker, og tettere integrasjon med frontendene.

Hva synes du er spennende i webutviklingsverdenen fremover?

Ingenting er statisk – og kanskje spesielt i frontend-verdenen. Men hva er det Bekkere gleder seg til i tiden som kommer?

Det aller mest gjentakende temaet var RSC – eller React Server Components. For de uinnvidde, så er RSCer en React-komponent som bare rendres på serveren. Det er jo flott for de komponentene som er tunge og fulle av JavaScript som ikke egentlig trengs på klienten – som for eksempel et markdown-bibliotek eller kode-highlighting. Det er fortsatt ganske nytt og spennende, og det er nok mange som gleder seg til at det blir bredere støttet og inkludert i en stabil versjon av React.

Mer generelt, så vi også at det at mer skjer på serveren, er noe vi gleder oss over. Vi har gått gjennom en komplett syklus de siste årene, fra serverside-rendra apper, via klientside-rendra apper, og nå er vi tilbake igjen. Fordelen er jo at sluttresultatet er mange ganger bedre og mer fleksibelt enn det vi hadde i 2013. Men som vi viste tidligere, så er det fortsatt et stykke igjen til flesteparten av oss bruker det i produksjon. Det blir spennende å se hvor fort det tallet beveger seg fremover.

Bortsett fra dette, så vi også at det var mye spenning rundt tematikker som WASM, Elm-vedlikehold, AI-verktøyenes inntog og Rust-tooling. Her er det ingen tid til å hvile kompetansemessig, med andre ord.

Hva synes du er vanskelig i frontend-utvikling for tiden?

Alt er selvfølgelig ikke rosenrødt i frontend-landskapet heller. Det er alltid mye nytt, det er alltid mye kompleksitet, og det er alltid tradeoffs når man skal jobbe i frontenden. Og Bekkere hadde opptil flere ting de ønsket å påpeke.

Mange synes styling var vanskelig. Det at det er så mange forskjellige teknologier, kombinert med stadig videreutvikling innen CSS, og ofte et kompetanseetterslep, gjør at styling ofte fører til ganske mye frustrasjon. Bør man bruke CSS Modules? Styled Components? Eller kanskje Tailwind? Det er kanskje ikke så rart å forstå at folk synes det er vanskelig.

En annen frustrasjon mange luftet var at det er vanskelig og tidkrevende å holde avhengigheter oppdatert. Vi bruker stadig flere tredjepartsbiblioteker, som igjen bruker egne tredjepartsbiblioteker, som igjen… Det er ikke så rart at det blir en komplisert affære! Spesielt når man bryter kontrakten man skal følge i semantisk versjonering, eller innfører nye bugs når man fikser gamle. Fra et sikkerhetsperspektiv er det kanskje ekstra vanskelig – for hvor enkelt er det å få oversikt over alt denne tredje-, fjerde- og femteparts koden gjør? Definitivt en vanskelig utfordring, som blir spennende å følge fremover.

Selv om React er et populært valg i Bekk, ser vi også at det er endel av oss som synes det er vanskelig. Og det er kanskje ikke så rart. For etterhvert som React har modnet, har det også blitt mer og mer komplisert. Man har muliggjort mer komplekse interaksjoner, på bekostning av hvor enkelt det er å forstå “alt” React tilbyr.

Andre frustrasjoner inkluderte Safari-bugs, å følge med på alt som skjer, typesikkerhet og pakkehåndtering. Vi er ikke helt i mål, med andre ord.

Hvor viktig er det for deg å være på det nyeste kuleste av frontend-teknologi

Det var spennende å se hvordan denne kurven kom til å forme seg. Var vi en gjeng med teknologioptimister, som kastet seg rundt for å teste det nyeste kuleste i prod? Eller var vi en gjeng sirumpa laggards, som var mer risikoaverse enn eventyrlystne?

Svaret så ut til å ligge et sted i midten, med en liten preferanse mot eksperimentering. Ingen av ekstremene var spesielt godt representert, og de aller fleste la seg et sted mellom “trygt og godt nok” og “spennende med nye-ish greier”.

Vi tror at dette er akkurat der vi burde være. Vi burde være eventyrlystne nok til å utforske ny teknologi, samtidig som vi ikke burde risikere kundene våre sine rykter og forretningsmodeller på å pushe den nyeste alpha-versjonen til produksjon. Vi synes nye ting er gøy, og er klare for å integrere det i løsningene våre når det blir stabilt nok, samtidig som det er mange nok av oss som tør å holde tilbake nok til å ikke gå på de største smellene.

Refleksjoner

Dette var en lang artikkel – så om du har kommet deg helt hit synes vi du fortjener en liten applaus. Men vi synes det er verdt innsatsen for å se hva som faktisk beveger seg rundt om hos noen av Norges største IT-bedrifter.

Fortell oss gjerne hva dine egne opplevelser er! Ser du det samme som oss? Mener du vi har noen enorme blindsoner vi ikke tar inn over oss? Si gjerne ifra i kommentarfeltet eller på sosiale medier. Vi gleder oss til debatten!

State of Frontend i Bekk 2024 was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dette var uken for espressofedre ☕️, trippy skyer 🌥️ og endeløse løkker ➰. Og 2.412 ting skjedde i frontend-verdenen!

<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uken som var.

React Aria Components i v1

Som designsystem-entusiast følger jeg alltid litt ekstra godt med på nye komponentbiblioteker. Og få releases har vært mer etterlengtet enn denne. Gjengen hos Adobe som har fått friheten til å jobbe med et UU- og stylingvennlig komponentbibliotek har endelig kommet i mål med React Aria Components v1 – og for en innsats de har lagt inn!

I denne pakken får man nemlig over 40 høyst UU-vennlige komponenter du kan bruke til å lage relativt avanserte brukergrensesnitt. Alt har blitt utviklet i samarbeid med UU-eksperter, og man har gjort massevis av testing med ekte brukere underveis. Snakk om å skaffe seg helt gratis superkrefter til produktteamet!

Pakken har vært ute i beta en stund, men er nå endelig tilgjengelig i en mer produksjonsklar modus. Kanskje det er på tide å kaste ut den sjanglende datovelgeren din til noe som er litt enklere og bedre å bruke?

December 20, 2023 Release

Shadcn/ui med masse nytt

Et annet komponentbibliotek som har fått massevis av oppmerksomhet i 2023, er det noe merkelig navngitte shadncn/ui. Dette biblioteket har en litt annen approach enn andre biblioteker, i at det ikke er tilgjengelig på NPM. Istedenfor bruker man en CLI til å kopiere inn kode i din kodebase — slik at du kan gjøre alle tilpasninger du måtte ønske.

Forrige uke var det full lanseringsfest her også, med massevis av nye komponenter, som også gir deg litt mer avanserte verktøy til brukergrensesnitt-byggingen din.

Selveste shadcn (det er github-brukernavnet til personen bak) har en flott tråd der hen viser frem alt det nye:

shadcn on Twitter: "✨We've added new components to shadcn/ui and made improvements to the CLI.◆ Drawer, Carousel, Pagination, Sonner & Resizable◆ Support for custom Tailwind prefix◆ Shipping early next year: A new style with framer motion animationshttps://t.co/NknJtJiTH6 👇 pic.twitter.com/4TaZ4rVQZe / Twitter"

✨We've added new components to shadcn/ui and made improvements to the CLI.◆ Drawer, Carousel, Pagination, Sonner & Resizable◆ Support for custom Tailwind prefix◆ Shipping early next year: A new style with framer motion animationshttps://t.co/NknJtJiTH6 👇 pic.twitter.com/4TaZ4rVQZe

En shadcn/ui deep dive

Om du ble litt interessert i shadcn/ui etter avsnittene over, eller om du har testet det ut litt allerede, så kan neste artikkel være ekstra interessant.

Manupa har skrevet en fin deep dive rundt dette biblioteket, og hvilke patterns og tekniske valg som har blitt gjort underveis. Det kan være greit å ha et forhold til, siden det tross alt skal inn i kodebasen din!

The anatomy of shadcn/ui

Remix får klient-data-støtte

Remix slapp også en ny versjon i julestria. Den største nyheten er at man nå har en innebygget måte å hente data på i klienten! Remix er i utgangspunktet et server-sentrert React-rammeverk, men av og til er det rett og slett nødvendig å hente data på klientsiden også.

Remix v2.4.0 kommer med ny clientLoader eksport, som blant annet kan vente på server-loaderen til å bli ferdig. I tillegg kan den hente ny data fra klienten. Dette kan være veldig nyttig når du for eksempel ønsker å ha en ucachet datakilde på en ellers cachet side. Vi kommer til å bruke dette hos en kunde som har en status-liste som oppdateres ofte, på en side som caches hardt.

Dette er et steg i retning av å innføre en såkalt SPA-mode for Remix. Dette er en flott måte å skrive om eksisterende React-apper til å bruke Remix, uten å legge til en server med en gang. Det kan også være et smart valg for noen typer applikasjoner som krever mer interaksjon enn man vanligvis ser.

Les changeloggen her 🔽

remix/CHANGELOG.md at main · remix-run/remix

Remix-refleksjoner

Om du ikke har brukt Remix selv enda, kan det være smart å høre litt fra andres erfaringer før man tar det i bruk selv. Her har Solomon fra konsulentselskapet Viget skrevet en fin oppsummering av deres egen læring fra å lage et internt verktøy i Remix.

Thoughts on Remix | Viget

En guide til structuredClone

Av og til trenger man å klone et objekt, og alle objektene og arrayene inni. En såkalt “dyp klone”. Det har alltid vært en klønete ting å få til i JavaScript – inntil nylig. Nå har man nemlig fått en innebygget måte å gjøre det på!

structuredClone gjør nemlig det man brukte relativt store biblioteker til i gamle dager – gjennom native kode i nettleseren. Og om du lurer på hvordan du bruker det, fant jeg en skikkelig fin guide her:

Deep Cloning Objects in JavaScript, the Modern Way

(PS — riktignok fra januar, men jeg leste den først forrige uke. Så i min bok er det fortsatt dagsrelevant 😄)

Bonus — frontend-artikler fra bekk.christmas!

Bekk har i år som de siste 6 årene laget et sabla kaos av faglige artikler i desember. Og den siste uken har det kommet hele 12 artikler som relaterer seg til frontend. Vi leker ikke fagmiljø 🥰

Ta en titt da vel!

• Immutable state
• Slik lager du et bibliotek som støtter React Server Components
• Jotai: Build Your State with Atom Precision
• Ta kontroll på skjemaelementet!
• Tre Grids for generasjon Flex
• Lær deg å bruke VoiceOver med tre, enkle kommandoer
• 🔥 Prettier Config considered harmful
• UseEffects only for side effects
• Three techniques for faster React apps
• Hva er greia med useRef og forwardRef?
• Making an accessible loading button: Aria-disabled with friends
• Get typesafe APIs with Zod and ChatGPT

Tusen takk for følge i år — sees igjen neste år!

ForrigeUke (uke 51, 2023) was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dette var uken for nostalgia 🚬 , koselige pranks 👮‍♀️ og hyggelige øyeblikk 🐶. Og hvor jeg åpenbart var endel på instagram 🙈. Men det skjedde fortsatt haugevis av ting i frontend-verden, og nå skal du få en kjapp oppsummering!

<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uken som var.

Svelte får runer!

Svelte har lenge vært et yndet rammeverk for folk som setter pris på reaktiv kode. Man endrer en variabel, som om det var vanlig JavaScript, og appen din oppdaterer seg perfekt. I alle fall så lenge du er inne i en .svelte fil.

Men beveger du deg utenfor de trygge rammene til Rich Harris’ kompilator, blir det fort mer utfordrende. Og da kan det være greit å ha noen litt kraftigere verktøy tilgjengelig — selv om de kanskje er hakket mer hårete å bruke.

I Svelte 5 kommer vi til å møte på “Runes”, som er et nytt konsept for å forenkle det å skrive reaktiv kode på tvers av store og mer avanserte applikasjoner, og ikke minst på tvers av både .svelte-filer og .js-filer.

Reaksjonene har vært litt delte, spesielt siden syntaksen er hakket verre enn den var, men om det skaper et bedre sluttprodukt, så er det nok verdt det for de fleste.

Les introduksjonsbloggposten her!

Introducing runes

Next blir (enda) raskere

Hver gang jeg ser en oppdatering av Next, så er de alltid raskere. Og sånn uforholdsmessig mye raskere. 40 % raskere her, 100 % raskere der, og halvparten så mye minnebruk liksom. Hvor raskt kan det bli?!

Next.js kom ut med en ny minor-versjon — 13.5. Og også denne gangen ble det noen enorme forbedringer. 22 % raskere startuptid lokalt, 29 % raskere hot module reloading, 40 % mindre minnebruk og – min favoritt – “over 438 bugs patched!”. Så… 439 bugs patched da, I guess?

Men selv om jeg peker nese, er det utrolig motiverende å se teamet bak Next.js fortsette å forbedre både ytelse, utvikleropplevelse og alt annet rundt rammeverket. Det er ikke en jobb som gjør seg selv, og de fortjener massiv kudos for arbeidet som gjøres 🙌

Next.js Conf

Om du jobber med Next.js (eller har lyst til å lære deg det), kan jeg anbefale å bli med på gratis-konferansen deres – Next.js Conf — som går av stabelen (i San Francisco og online) 26. oktober. Du kan få en gratisbillett her.

RFC for API routes i Expo

For de av dere som jobber med kryss-plattform apputvikler, så kom det også et litt spennende nytt forslag i Expo-verdenen sist uke.

Expo er et slags rammeverk som sitter på toppen av React Native, og tilbyr en rekke snasne APIer og tjenester. De har blant annet laget sin egen router – Expo Router – som fungerer ganske bra. Ulempen er selvfølgelig, som med alle rammeverk, at du binder deg ganske til masta.

Forslaget jeg nevnte innledningsvis introduserer en måte for mobilutviklere å lage enkle API-endepunkter, der de kan gjøre sikre kall mot autentiserte tjenester. Det høres jo egentlig ut som en drøm – og er definitivt en av de produktivitetsboosterne jeg elsker mest med fullstack-utvikling i Remix og Next.js.

Når alt det er sagt — forslaget er fortsatt et forslag, og det er nok en stund til det er å se ute i produksjon. Men jeg lover å teste det ut så snart jeg kan!

Det var det for denne uken. Ikke så mange saker som beveget seg kanskje, der det definitivt mest spennende var Sveltes nye runer. Vi får ønske dem lykke til, og håpe på en ellers produktiv frontend-uke. Sees!

ForrigeUke (uke 38, 2023) was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dette var uken jeg løste produktivitet for utviklere 📈, nye lekkasjer fra Next 14 🙈 og Dan Abramov kaster brannfakler 🔥. Og 242 023 ting skjedde i frontend-verdenen!

<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uken som var.

Hils på Panda CSS 🐼

Jeg har alltid vært fan av Chakra UI. Det er enkelt å komme i gang med, har de fleste komponentene du trenger, og er enkelt å tilpasse via temaer og fargemoduser. Men det har noen nedsider. Det er stort og tungt, det avhenger av Emotion (som er litt gammeldags, er det ikke?) og ikke minst — fungerer skikkelig dårlig med React Server Components.

Så hvorfor liker jeg det fortsatt? Vel, mens vi har sittet her og klaget, har Chakra-sjef og gladfis Segun Adebayo brettet opp ermene for å lage noe som fungerer mye, mye bedre.

Panda CSS er et CSS-in-JS-rammeverk som genererer statiske stiler build-time – så det ikke trenger å sende en full CSS-in-JS-motor til klientene. Du kan fortsatt bruke såkalte style props (<Box marginTop={2} /> for eksempel), og skrive koden din som du gjør i Chakra UI. Du får riktignok ingen ferdige komponenter ut av boksen med Panda, men det gjør det enkelt nok å style dine egne.

Segun har også nevnt at det er på planen for Chakra UI å migrere over til Panda CSS, slik at du kan bruke Chakra i applikasjoner som bruker React Server Components.

Alt er åpenbart ganske nytt og ikke klart for å skrive om appen din i enda, men det virker som en veldig fin løsning for en vanskelig teknisk utfordring. Les mer på hjemmesiden deres!

Panda CSS - Build modern websites using build time and type-safe CSS-in-JS

Vercel slipper ny AI SDK og template 🤖

Okei, jeg vet vi holder oss unna AI-ting her i ForrigeUke, men denne var såpass interessant at jeg snikern inn allikevel.

Vår alles favoritt-trekantselskap Vercel har nemlig sluppet en snasen liten SDK, som gjør det helt fantastisk enkelt å lage chat-baserte AI-applikasjoner i nettleseren.

Dette kan være grunnlaget for mang en morsom POC på landets mange kontorer, og som kan hjelpe med å løse faktiske brukerbehov på null komma niks.

Introducing the Vercel AI SDK: npm i ai - Vercel

Du kan tilogmed streame responsen, som gjør det å lage en ChatGPT klone til, om ikke en lek, et ikke like skummelt eksperiment som man skulle tro.

Sjekk ut eksempel-appen deres her:

Next.js AI Chatbot

Lag dybdebaserte blur-effekter med CSS

Shu på Next.js teamet er ikke bare en rakker på React-greier — han kan også en ting eller tretten om CSS.

Forrige uke så delte han nemlig en skikkelig kul demo der han viser frem hvordan man kan lage en dybdebasert blur-effekt med ren CSS, og hvor kult det kan se ut:

Shu on Twitter: "Depth-based blur in CSS.https://t.co/kB7gFdbh5k (Chrome preferred) pic.twitter.com/W3RPVgh799 / Twitter"

Depth-based blur in CSS.https://t.co/kB7gFdbh5k (Chrome preferred) pic.twitter.com/W3RPVgh799

Jeg er litt usikker på hva man skulle brukt det til, men jeg tipper det trigger noen kreative idéer rundt om hos folk.

MDX ute i versjon 2.0

Hvis du har skrevet en React-basert blogg de siste par årene, har du kanskje vært borti MDX. MDX er en extension til Markdown-formatet, som lar deg skrive JSX for å rendre forskjellige komponenter mellom det vanlige innholdet.

MDX har vært utrolig nyttig for veldig mange, og i forrige uke kom det nemlig en helt ny major versjon, som inneholder en rekke nye features, raskere kompilering, mindre bundle size og full React Server Components-støtte. Også er alt TypeScript da!

Les mer om den nye major-versjonen og hva den inkluderer her:

MDX 2 | MDX

Og det var det vi kom over denne uken! Ikke dårlig bare det, gitt at hele Reddit var nede denne uken! Tusen takk for at du tok turen innom, og velkommen tilbake neste uke ❤

ForrigeUke (uke 24, 2023) was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dette var uken for litt lettvekts trolling 🧌 , ny innsikt 🤯 og en god gammeldags prank 🌭. Og gjett hvem som oppsummerer frontend-verden denne uka! 🧓

<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uken som var.

CSS Zen Garden fyller 20 år!

Jeg vet ikke hvordan dere startet deres karrierer som frontend-utviklere, men jeg husker fortsatt første gang jeg snublet over den nå ganske sagnomsuste nettsiden CSS Zen Garden for mange (mange!) år siden. For de som ikke kjenner til denne siden, så er det en standardisert bit med HTML, med noen klassenavn på, som forskjellige folk har fått til å se helt forskjellig ut kun med CSS.

Jeg ble så fascinert av mulighetene man hadde, at jeg satt meg ned og nileste alt jeg kunne komme over av CSS-litteratur i år fremover. Jeg var riktignok ganske tidlig i tenåra, så noen imponerende kloner ble det ikke – men det førte til en kjærlighet jeg har til CSS den dag i dag.

Om du ikke har vært innom denne rolige internetthagen før, anbefaler jeg at du tar et besøk, og klikker deg rundt til et par eksempler. La deg inspirere. La deg imponere. Og lag din egen, bare for moro skyld. Tipper det er gøyere uten å bruke tabeller til layout, som jeg gjorde 🙈

CSS Zen Garden

Next.js 13.4 er ute!

Manges React-rammeverk numero uno – Next.js – er ute med en ny minor-versjon, med relativt major endringer!

For det første er deres nye måte å strukturere sider på – “app”-mappa – ute av beta, og nå den anbefalte måten å lage sider på. Det høres kanskje ikke så veldig spennende ut, men det er et ganske stort paradigmeskifte – både for Next.js og React.

App-mappa til Next.js lar deg nemlig ta i bruk såkalte “server components” – komponenter som bare kjører på server-siden. Det gjør at du ikke trenger å sende hele markdown-parsing biblioteket eller tekster for alle språk til klienten – du sender i stor grad bare ferdig-rendret HTML som vises til brukeren raskere enn noen gang før.

For å deale med endringer, har Next også laget støtte for noe de kaller “Server Actions” – en litt ny og forbedret måte å deale med skjema-innsending på. Det har også endt opp med å være ganske interessant, både fra et Next-perspektiv og fra et React perspektiv. Disse kommer nemlig til selv klientside-apper!

Om du er interessert i dette, så vil jeg anbefale å ta en titt på den offisielle release-posten deres – dette er skikkelig spennende teknologi og gøyale fremskritt for både oss utviklere og sluttbrukeropplevelsen.

Next.js 13.4

Vercel får støtte for KV-stores og Postgres 🤯

Som om det ikke var nok moro fra Vercel i det siste, har de også lansert et par nye tjenester jeg ser for meg kan være veldig nyttige – både for mindre prosjekter og mange større bedrifter.

Nå får man nemlig støtte for både key-value stores (les Redis) og PostgreSQL, distribuert ut til der brukerne dine sitter. Det betyr latterlig lav latency, og ikke minst en veldig mye bedre brukeropplevelse. Se bare hvordan det anbefales at man skriver koden sin fremover:

import { sql } from '@vercel/postgres';

export default async function UserPage(props) {
  const { rows } = await sql`SELECT * FROM users WHERE id ${props.params.id}`;
  return <h1>Hei hei, {rows[0].name}</h1>;
}

Dette er ganske kult, spesielt siden det også sikrer oss mot SQL-injection angrep og en rekke andre ulumskheter.

Gleder meg til å teste ut dette ved neste anledning. Selv om det muligens gir litt PHP-vibber for noen 😁

• Vercel Postgres: Scalable SQL for the web - Vercel
• Vercel KV: Now in the Vercel dashboard - Vercel

RemixConf!

Egentlig ikke en ForrigeUke-post verdig kanskje, for dette skjer denne uken – i dag og i morgen – men jeg gleder meg såpass mye til denne eventen at jeg ikke klarer å vente til neste uke.

Remix har lenge vært en reell utfordrer til hegemoniet Next.js har hatt på React-rammeverksfronten, og det lages stadig flere sider med hva jeg liker å kalle mitt goto-rammeverk. Men den siste tiden har det vært relativt stille fra gjengen bak – noe som jeg håper kan være en slags stillhet før stormen av nyheter.

For hva slags svar har Remix-gjengen til alle de nyhetene Vercel og gjengen har sluppet i det siste? Kommer vi til å se støtte for Server Components? Server Actions? Eller noe av det andre React-gjengen har kjørt på med i det siste?

Stemningen er til å ta og føle på, og jeg kommer i alle fal til å sitte spikra foran skjermen for å følge med i morgen. Det kan du også, tipper jeg, selv om de ikke har sagt eksplisitt at noe skal streames. I alle fall verdt å følge med på.

Remix Conf - May 2023

React Aria Components får litt traction!

De som kjenner meg vet at jeg er litt over snittet glad i designsystemer. Jeg bruker hverdagene mine på å hjelpe Vy sette sammen sitt, og har vært med på å lage en god del forskjellige designsystemer og komponentbiblioteker opp gjennom.

Derfor er jeg så glad for å se Adobes React Aria Components-bibliotek få mer traction – både i TL;DR-nyhetsbrevet og på HackerNews. Vi nevnte det for et par uker siden, men om du gikk glipp av det da, så er dette biblioteket et sett med ustylede React-komponenter som lar deg lage alle de tingene som er vanskelig å lage med ren HTML. Vi snakker combobokser, autosuggests og datepickers, for å nevne noen.

Før måtte man skru sammen disse komponentene selv, med hooks fra react-aria-biblioteket, men nå kan man spare seg ganske mye arbeid ved å bare bruke dette biblioteket ut av boksen. Og med den evig økende populariteten til Tailwind, kan det hende at biblioteker som Chakra UI og Material UI kanskje kan få en reell utfordrer i det spacet.

Det var det viktigste som skjedde i frontend-verdenen min denne uka i alle fall. Og selv om både Angular droppet en ny (visstnok veldig mye bedre) versjon, og Quik kom ut i v1.0, så tror jeg det får være for de spesielt interesserte.

Det er en fin tid å være glad i frontend i alle fall. Det er det.

ForrigeUke (uke 18, 2023) was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Denne artikkelen viser deg hvordan du kan lage et enkelt typesikkert oversettelsesverktøy for React på noen få linjer kode, uten at du trenger å dra inn noen eksterne avhengigheter. Og så lærer du kanskje litt om TypeScript underveis.

Steg 0: Lag en slagplan

Før man begynner på et slikt lite prosjekt, så kan det være greit å tenke seg litt om hva det innebærer. I vårt tilfelle er TODO-listen slik:

• Bestemme hvordan bruken skal se ut
• Definér hvilke språk vi skal støtte
• Lage en måte å oversette tekst på
• Legge til støtte for dynamiske tekster og nøstede objekter
• Lage typer som gjør at vi ikke kan skrive noe feil.

Med den oversikten på plass, kan vi hoppe inn i å lage ting!

Steg 1: Bestemme hvordan bruken skal se ut

Det finnes mange måter å designe hvordan et oversettelsesverktøy skal brukes på. Jeg lener meg på mitt favoritt-bibliotek fra et tidligere Bekk-oppdrag, nemlig Leiles lobo-t. Der ser bruken sånn ca slik ut:

const Eksempel = (props) => {
  const { t } = useTranslation();
  return <p>{t(texts.example)}</p>
};
const texts = {
  example: {
    no: 'Eksempel',
    en: 'Example',
  }
};

Man henter ut en funksjon t fra en hook vi kaller useTranslation , også sender man inn et objekt med de forskjellige språkene for en gitt tekstnøkkel.

I tillegg til denne funksjonaliteten, bør man også ha en måte å endre språk på (det kommer vi tilbake til senere).

Det er to fordeler med dette API-designet slik jeg ser det:

1. Man får typesikre tekster med auto-complete og hele smæla ut av boksen
2. Man kan samlokalisere tekstene sammen med koden som rendrer dem

Det er én ulempe også, og det er at man må laste inn tekstene for alle språkene man skal støtte på hver side. Det har ikke vært en utfordring jeg har vært borti enda, men det kan være greit å være klar over.

Steg 2: Definere hvilke språk vi skal støtte

Språkene du skal støtte er typisk ikke en veldig dynamisk ting akkurat, så la oss bare hardkode dem inn i dette biblioteket, med en enum!

enum Language {
  English = "en",
  Norwegian = "no",
}

Verre var det ikke egentlig. Du kan også bruke en vanlig const om du ikke liker enums, da.

Ah, jeg elsker korte steg.

Steg 3: Lage en måte å oversette tekst på

Nå er det på tide at vi får dette til å fungere. APIet vårt går ut på å ha en hook som heter useTranslation , så da kan vi jo begynne med å lage den.

function useTranslation() {
  const currentLanguage = getLanguageFromSomewhere();
  return {
    t: (translationObject) => translationObject[currentLanguage]
  };
}

Vi henter språket fra ett eller annet sted, og returnerer en funksjon t , som rett og slett bare velger ut riktig språknøkkel for oss. Ganske grei skuring.

Men hvor får vi dette språket fra? Det finnes forskjellige løsninger for forskjellige rammeverk, men ett som fungerer overalt er å lagre valgt språket i en eller annen tilstand, og tilgjengeliggjøre det gjennom en context. Slik kan det se ut:

const TranslationContext = createContext();
const TranslationProvider = (props) => {
  const currentLanguageState = useState<Language>(props.defaultLanguage);
  return (
    <TranslationContext.Provider 
      value={currentLanguageState}
    >
      {props.children}
    </TranslationContext.Provider>
  );
}
const useTranslationContext = () => useContext(TranslationContext);

Så wrapper man appen sin i TranslationProvider-en, sender inn et default-språk, og oppdaterer useTranslation -koden sin:

function useTranslation() {
  const [currentLanguage, changeLanguage] = useTranslationContext();
  return {
    t: (translationObject) => translationObject[currentLanguage],
    changeLanguage,
  };
}

Vips, så har man et fungerende oversettelsesrammeverk.

Steg 4.1: Legge til støtte for dynamiske tekster

En feature du mest sannsynlig kommer til å ønske deg ganske raskt er dynamiske tekster – tekster som kan ta imot argumenter!

Slik kan de se ut:

const texts = {
  greeting: (name, age) => ({
    no: `Hei ${name}, den ${age} år gamle magikeren`,
    en: `Hello ${name}, the ${age} old magician`
  })
}

Dette fungerer faktisk rett ut av boksen allerede!

const Eksempel = ({ name, age }) => {
  const { t } = useTranslation()
  return <p>{t(texts.greeting(name, age))}</p>
}

Nok en lett seksjon å fullføre, med andre ord.

Steg 4.2: Legge til støtte for inline JSX

Okei jeg skal ikke kaste bort tiden din. Dette funker også rett ut av boksen. Til og med med dynamiske tekster, om du vil gå helt amok.

Her er et enkelt eksempel på hvordan det kan se ut.

const texts = {
  eksempel: {
    no: <><strong>Gratulerer!<strong> Dette er gøy.</>,
    en: <><strong>Congrats!<strong> This is fun.</>,
  }
}

Bare husk å ikke gå helt amok med inline JSX-en — du vil ikke at texts-objektene dine skal bli altfor store heller 🤔

Steg 5: Legge til typer for en enda sikrere hverdag.

Nå har vi noe som fungerer sånn tålelig bra. Men det er fortsatt enkelt å skyte seg i foten! Vi har ikke brukt noe særlig typesikring enda, så det er kanskje ikke så rart. Heldigvis er det neste post på programmet!

Først, så tenker jeg vi kan definere hvordan et av disse objektene med oversettelser kan se ut. Det er et objekt med forskjellige språk-nøkler (en, no osv) som nøkler, og tekst som returverdi.

type TranslationObject = { [key in Language]: string | ReactNode }

Men så må vi huske at vi kunne sende inn en funksjon også (for disse dynamiske tekstene). Den typen ser slik ut:

type TranslationFunction = (...args: (string | number)[]) => TranslationObject

For å gi en god type til texts -objektet vi plasserer alle tekstene våre i, kan vi da kombinere litt:

type Translations = Record<string, TranslationObject | TranslationFunction>
// evnt
type Translations = {
  [key: string]: TranslationObject | TranslationFunction
}

Bonus: Om du vil kunne lage litt dypt nøstede objekter av disse texts-objektene vi lager, kan du bruke noe som høres skumlere ut enn det er — rekursjon!

type Translations = {
  [key: string]: TranslationObject | TranslationFunction | Translations
}

En type som refererer til seg selv? Det hørtes skummelt ut! 🤯 Men det eneste det muliggjør er at man kan lage ting som dette:

const texts: Translations = {
  meta: {
    title: { no: 'Min side', en: 'My page' },
    description: { no: 'En side om meg', en: 'A page about me' },
  },
  hero: { no: 'Dette er min side', en: 'This is my page' },
}

Bonus 2: Selv om den castingen over fungerer finfint, så er jeg ikke så fan av syntaksen. Derfor lager jeg heller min egen funksjon — createTexts — som gjør den for meg. Den ser slik ut:

export function createTexts<T extends Translations>(texts: T) {
  return texts;
}

Helt til slutt må vi også huske på å oppdatere signaturen til t -funksjonen vår:

t: (translations: TranslationObject) => translations[language] as string,

Merk at vi type-caster returverdien til å være string . Det stemmer jo strengt talt ikke – vi kan få tilbake JSX også. Men siden man typisk returnerer strenger, og strenger er gyldig JSX, så fungerer dette overraskende fint.

Her kan du se en demo. All koden vi har skrevet ligger i i18n.tsx -fila,og hvordan man bruker det ligger i index.tsx og app.tsx .

Veien fremover

Det å lage oversettelsesverktøy er en komplisert oppgave, og det er mange features her som jeg har droppet for enkelhetens skyld. Men det er heldigvis ikke så mange du trenger å skrive selv.

Formattering av tid, datoer, tall, lister og en haug andre ting får du fra Intl -pakken til moderne nettlesere. Hva man før brukte et titalls biblioteker til er nå bygget inn i plattformen! 💪

Og da er det kanskje ikke noe vits i å ha en egen pakke for å oversette tekster. Spesielt når det er så gøy å skrive selv!

Jeg håper du har likt denne artikkelen, og at den inspirerer deg til å gjøre noe lignende på ditt egne prosjekt en dag. Om du har noen spørsmål håper jeg du tar kontakt, så skal jeg svare så godt jeg kan.

Lag ditt eget typesikre oversettelsesbibliotek! was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Denne artikkelen gir deg en rask introduksjon til de hva landemerker i HTML er, hvilken rolle de spiller, og hva som skjer når du bruker dem.

Hva er landemerker?

I HTML er landemerker — i likhet med hva de er i den fysiske verden — noe man kan navigere etter i et ellers ukjent landskap. De gir deg noen faste holdepunkter til hva som ligger hvor på siden din, og gjør det enklere å komme seg dit.

Landemerker lager man med ganske vanlig HTML. Du har kanskje sett dem før — <main> , <nav> , <footer> , <header> og <section> er noen eksempler. Men når bør du bruke hvilke? Og hva er egentlig effekten av å bruke dem?

Regioner og rotorer

Det mest grunnleggende du kan gjøre for å forbedre sidestrukturen din er å strukturere innholdet ditt i relevante bolker. For en “vanlig” nettside kan det se slik ut:

<body>
  <header>
    <nav>
      <ul>
        <li><a href="/meg">Meg</a></li>
        <li><a href="/arbeider">Arbeider</a></li>
      </ul>
    </nav>
  </header>
  <main>
    <section>
      <h1>Velkommen til min nettside</h1>
      <a href="/meg">Lær mer om meg</a>
    </section>
    <section>
      <h2>Arbeider</h2>
      <p>Jeg har gjort mye spennende.</p>
      <a href="/arbeider">Se arbeidene mine</a>
    </section>
  </main>
  <footer>
    <nav>
      <ul>
        <li><a href="https://twitter.com/selbekk">Si hei på Twitter</a></li>
        <li><a href="mailto:kristofer.selbekk@bekk.no">Send meg en epost</a></li>
      </ul>
    </nav>
  </footer>
</body>

Dette har to fordeler:

1. Det er enklere å lese koden i forhold til om alt hadde vært <div> -tagger
2. Det gir nettleseren mulighet til å lage en mer informert struktur som assisterende teknologi kan bruke.

Åpner du koden over i Firefox, og åpner “Accessibility”-fanen i utviklerverktøyene vil du få se følgende struktur (også kjent som “accessibility-tree”):

Hadde du byttet ut alle de semantiske elementene med <div> -tagger ville du fått følgende struktur:

Ikke den største forskjellen ved første blikk kanskje, men for skjermlesere er det natt og dag. Faktisk så stor forskjell at om du bruker den første versjonen (den med alle landemerkene), får du en helt ny seksjon i kontrollpanelet skjermleserne ofte kaller en “rotor” — verktøyet man bruker for å navigere nettsider.

Dette kan være utrolig nyttig for brukerne dine — plutselig trenger de ikke lenger utforske strukturen på siden din i blinde!

Navngi landemerkene dine

Selv om det vi fikk til over var en soleklar forbedring over det man ofte kaller “div-suppe”, kan vi forbedre dem litt til. Vi kan nemlig gi dem noen navn. Det kan vi gjøre med aria-label . Under har vi endret menykoden vår til å gi den et navn:

<header>
  <nav aria-label="Hovednavigasjon">
    <ul>
      <li><a href="/meg">Meg</a></li>
      <li><a href="/arbeider">Arbeider</a></li>
    </ul>
  </nav>
</header>

Det ser straks bedre ut i rotoren:

Hvilke landemerker finnes?

Det er en rekke forskjellige HTML-tags du kan bruke for å opprette landemerker:

• <header>
• <footer>
• <main>
• <nav>
• <section>
• <article>
• <aside>
• <form>
• <input type="search">

De kan nøstes på forskjellige måter, for å bygge en dypere informasjonsstruktur. Her er et eksempel av en imaginær blogg jeg kodet opp:

Snakk om å skape en flott måte å navigere en side på! Her har du full oversikt over alt innhold, uten å ha tabbet deg så mye som en rad nedover sidestrukturen 💪

Bruk landemerker for det de er verdt!

Landemerker er webbens egne innebygde måte å navigere strukturert innhold på. Det gjør at du kan dele opp siden din i logiske seksjoner, som man kan bevege seg rundt i uten å kunne for mye om siden eller applikasjonen din fra før av.

Ikke er det mye arbeid heller. Bruk litt tid på å lære deg når du skal bruke de forskjellige landemerkene, sleng på relevante labels der de trengs, og ikke minst, sjekk hvordan det oppleves i en skjermleser!

En enkel intro til landemerker i HTML was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Denne artikkelen tar for seg en veldig nyttig teknikk for interaktive nettapplikasjoner, nemlig aria-live -attributten i HTML. Husker du denne, er du langt på vei til å løse noen UU-utfordringer i koden din.

Når trengs aria-live?

Før vi dykker ned i hvordan aria-live -attributten fungerer, kan det være greit å vite i hvilke situasjoner den er nyttig.

I gamle dager, når man laget websider, var det meste innholdet statisk. Man trykket på lenker, og man ble sendt til nye sider. Man fylte ut skjemaer og sendte dem inn, og ble videresendt til nye sider. Kanskje den samme siden, med noen feilmeldinger på — men fortsatt via en ny sidelast. Dette fungerte jo greit nok, selv om det kanskje ikke var like interaktivt og responsivt som i dag.

Dagens nettløsninger er ofte modellert som applikasjoner, med mye interaktivitet bygget inn. Det er validering av skjemafelter mens du fyller dem ut, det er asynkron server-kommunikasjon, og det er generelt veldig mye som endrer seg uten noen form for navigasjon.

Hadde skjermleseren din lest opp alt som forandret seg til enhver tid, ville man nok opplevd det som slitsomt. Du er ikke så interessert i at produktkarusellen i bunnen av siden du er på roterte til neste produkt, for eksempel.

Det er allikevel tilfeller der du vil få beskjed om at noe har skjedd. Toast-meldinger som popper opp, nye chatmeldinger, og feilmeldinger når du fyller ut et skjema er bare noen eksempler der det kan være nyttig å få beskjed. Og det er nettopp i de tilfellene det er greit å vite om aria-live.

Hvordan funker aria-live?

Bruksområdet for aria-live er ganske greit – hvis du vil at en skjermleser skal lese opp at innhold endrer seg før man navigerer seg til det, trenger man å legge på en aria-live-attributt.

Her er et enkelt eksempel på hvordan det kan se ut:

<div aria-live="polite">
  Klokka er 15:29
</div>

aria-live kan ha tre forskjellige verdier – off , polite og assertive , der off er default-verdien (samme som å ikke ha med aria-live i det hele tatt). Forskjellen på polite og assertive -verdiene er når endringen leses opp. aria-live="polite" venter til skjermleseren er ferdig med å lese opp det den holdt på å lese opp, mens aria-live="assertive" avbryter og leser opp endringen med en gang. Det anbefales å bruke polite i de fleste tilfeller, da assertive -versjonen ofte oppleves som masete og irriterende om den brukes for mye

Hvordan oppleves aria-live?

Her er et kodeeksempel på hvordan aria-live fungerer. Du kan slå på din egen skjermleser og høre hvordan det oppleves:

Om du ikke har en tilgjengelig, så kan jeg forklare det med litt tekst.

Hadde man ikke hatt noen aria-live -attributt, ville opplevelsen vært slik:

[skjermleser]: Knapp, “klikk da”
[meg]: <klikk>
[skjermleser]: …
[meg]: <klikk en gang til>
[skjermleser]: …

Om man legger til aria-live=”polite", så er opplevelsen ca slik:

[skjermleser]: Knapp, “klikk da”
[meg]: <klikk>
[skjermleser]: 1
[meg]: <klikk en gang til>
[skjermleser]: 2

Møt aria-atomic

Som du kanskje la merke til, så leste skjermleseren bare opp selve tallet som endret seg. Noen ganger hadde det vært fint om den leste opp hele teksten i aria-live-regionen hver gang noe endret seg der inne — ikke bare det ordet eller tallet som endret seg!

Det kan man få til med attributten aria-atomic=”true" . Om du legger til den, vil opplevelsen endre seg slik:

[skjermleser]: Knapp, “klikk da”
[meg]: <klikk>
[skjermleser]: Du har klikket 1 ganger
[meg]: <klikk en gang til>
[skjermleser]: Du har klikket 2 ganger

Velger man å tilgi entall/flertallsfloken så er det en ganske mye mer snedig opplevelse. Det er ikke alltid man vil ha det slik – spesielt om det er mye innhold – men det kan være et greit triks å ha i baklomma.

…og aria-relevant

Ut av boksen så vil skjermlesere kun lese opp hva som legges til eller endres i en aria-live -region. Men av og til kan det hende man vil lese opp ting som fjernes også. Et eksempel kan være når man har en liste over brukere i en chat, der man vil få lest opp når noen fjernes fra lista.

aria-relevant lar deg spesifisere hvilke endringer som er relevante for skjermleseren å lese. Det finnes 3 forskjellige verdier – additions , removals og text . Om du vil ha alle tre kan du også bruke en fjerde verdi all . Om den ikke defineres så er defaulten additions text (jepp, man kan ha flere, fordelt med mellomrom).

Her er et eksempel der vi legger til en ekstra linje med tekst når man har trykket 3 ganger:

Slik vil det høres ut:

[skjermleser]: Knapp, “klikk da”
[meg]: <klikk>
[skjermleser]: Du har klikket 1 ganger
[meg]: <klikk en gang til>
[skjermleser]: Du har klikket 2 ganger
[meg]: <klikk en gang til>
[skjermleser]: Du har klikket 3 ganger. Alle gode ting er 3.
[meg]: <klikk en gang til>
[skjermleser]: Alle gode ting er 3. Du har klikket 3 ganger.

Det er ganske imponerende hvor stor kontroll man kan ha over skjermleseropplevelsen med et par ekstra attributter!

Implisitt live

Det finnes endel “presets” i HTML-verden, som gir deg endel aria-attributter ut av boksen. <header /> -taggen har for eksempel role="header" som en implisitt attributt, og <input type="search" />har role=”searchbox” . role -attributten fungerer også på samme måte — har også endel implisitte betydninger – spesielt for aria-live .

Bruker du for eksempel role="alert" , vil du automatisk få aria-live="assertive" uten å måtte spesifisere den. Bruker du role="status" , får du aria-live="polite" . Du finner en komplett liste på MDN.

Praktiske eksempler

Her er et par praktiske eksempler for hvordan man ville brukt aria-live:

Skjemavalidering

Når man lager skjemaer, har man som regel en eller annen type validering på innholdet. Og om man får en valideringsfeil, er det viktig at den leses opp. For å få til det, wrapper man input-feltet sitt i en <div /> med aria-live="polite" :

<div aria-live="polite">
  <label for="username">Brukernavn</label>
  <input id="username" name="username" />
  <div id="error-username"></div>
</div>

Om man oppdaterer innholdet i #error-username med JavaScript, vil det nå bli lest opp, selv om man fortsatt har fokuset i input-feltet.

En annen måte å vise feilmeldinger i skjemaer på er en boks på toppen av skjemaet etter man har prøvd å sende det inn. Det kan også løses på samme vis — sleng på en aria-live="polite" for å få den til å bli lest opp. aria-live bryr seg nemlig ikke om man har fokuset et helt annet sted på siden!

<form action="/api/login" method="post">
  <div aria-live="polite" id="error-summary"></div>
  <div>
    <label for="username">Brukernavn</label>
    <input id="username" name="username" />
  </div>
  <div>
    <label for="password">Passord</label>
    <input id="password" name="password" type="password" />
  </div>
  <button>Logg inn</button>
</form>

Som sist — endrer man #error-summary , blir det lest opp når skjermleseren er ferdig med å lese opp hva den holdt på med (mest sannsynlig navnet på knappen eller inputfeltet man hadde fokusert på.

Toasts og meldinger

Mange webapplikasjoner har implementert meldinger som dukker opp i noen sekunder, og forsvinner igjen. Det kan være greit å si ifra om til brukeren — og det med en gang.

I dette tilfellet trenger vi faktisk ikke å bruke aria-live direkte — vi kan heller bruke role="alert" – som kommer med en implisitt aria-live="assertive" , i tillegg til bedre generell tilrettelegging for skjermlesere.

<div id="toast" role="alert"></div>

Når denne fylles med innhold, avbrytes hva enn skjermleseren leser for øyeblikket til fordel for det som legges til i alert-boksen vår. Fokus forblir der brukeren var, og skjermleseren vil fortsette der den var, når alert-en er ferdig opplest.

TL;DR:

Om dette ble for mye informasjon å ta til seg på en gang, så husk i alle fall dette:

Om du oppdaterer innhold på nettsiden din, som du vil at brukeren skal få med seg, må du wrappe det innholdet i en tag som har attributten aria-live=”polite”. Haster det, kan du bruke aria-live=”assertive”. Men det haster mest sannsynligvis ikke.

MDN er som alltid en flott ressurs om du vil lese litt mer, eller sette deg mer inn i detaljene. Ta en titt på denne siden for mer informasjon.

Hvis du har noen spørsmål, eller har andre ting du vil legge til, så legg gjerne igjen en kommentar :)

En enkel guide til aria-live was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.