Blogg

Optimistic UI i React: grensesnittet som bevisst lyver

«Lik»-knappen reagerer umiddelbart, hjertet fyller seg, telleren øker – før serveren i det hele tatt har svart. Dette er ikke bare illusjonen om hastighet fra artikkelen om mikrointeraksjoner, det går lenger: grensesnittet viser en tilstand som ennå ikke eksisterer, og forutsetter at den snart vil gjøre det. Jeg går gjennom hvordan man bygger dette trygt – med reell tilbaketrekning fra løgnen når forutsetningen ikke holder – og hvorfor manuell setState pluss catch er en dårligere versjon av det useOptimistic gir.

CSS @layer: hvordan cascade layers avslutter krigen om spesifisitet

Verktøyklassen .mt-4 taper mot regelen .card .card__header .card__title, selv om den logisk sett burde vinne fordi den ble lagt til senere. Dette er ikke tilfeldig – det er spesifisitet som gjør nøyaktig det den er designet for å gjøre. @layer innfører en helt ny akse for å avgjøre konflikter, som virker før spesifisiteten, ikke sammen med den – og har én felle så mot-intuitiv at selv deler av dokumentasjonen på nettet bryter den.

Server Actions i Next.js: skjemaet som fungerer før JavaScript rekker å laste

«use server» ser ut som syntaktisk sukker for et fetch-kall til en API-rute – og nettopp derfor behandler de fleste implementasjoner den som et vanlig funksjonskall. Det er en feil med konkrete konsekvenser: hver funksjon merket «use server» blir et offentlig endepunkt på nettet, og et skjema bygget på denne mekanismen fungerer selv før JavaScript rekker å laste. Jeg går gjennom hva som faktisk skjer under dette direktivet, og hvor fellene ligger som ikke er åpenbare ved første blikk i dokumentasjonen.

CSS :has() — forelderen som vet hva som skjer inni

Et skjemafelt skal lyse rødt når input-en inni er ugyldig. Enkelt nok – bortsett fra at CSS i 25 år ikke kunne spørre et element om hva som skjer inni det, bare motsatt. Jeg går gjennom hvordan :has() snur denne retningen, hvordan den skiller seg fra vanlige kombinatorer, og hvor denne nye kraften faktisk koster ytelse.

Container Queries: komponenten som kjenner sin egen beholder, ikke viewporten

Det samme produktkortet ser flott ut i rutenettet og bryter sammen i en smal sidebar – til tross for nøye utvalgte media queries. Problemet ligger ikke i koden din, men i spørsmålet media query faktisk stiller: om bredden på skjermen, ikke om plassen komponenten faktisk fikk tildelt. Jeg går gjennom hvordan container queries flytter dette spørsmålet dit det burde vært stilt fra begynnelsen, og hva som egentlig skjer under overflaten når et element blir en «spørringsbeholder».

Oppretting av tilgjengelige komponenter for skjermlesere

Korrekt HTML er bare startpunktet. Se hvordan tilgjengelighetstreet faktisk fungerer, hvorfor ARIA oftere skader enn hjelper enn du skulle tro, og bygg en ekte accordion, en live region og fokushåndtering i Next.js sammen med meg.