I artikkelen om mikrointeraksjoner skrev jeg at transform og opacity animeres på kompositeringstråden, så selv en tung side ikke burde få knappeanimasjonen til å hakke. Det stemmer fortsatt – med ett forbehold den artikkelen ikke nevnte: hvis hovedtråden er blokkert av en lang JS-oppgave, får animasjonen kanskje aldri sjansen til å starte, fordi selve klikk-handleren står og venter i køen. INP er metrikken som måler nøyaktig dette gapet – og scheduler.yield() er en av de få måtene å faktisk lukke det på.
En liste med tusen kommentarer rendrer sakte, så du griper til react-window – og i bytte mot jevn scrolling mister du Ctrl+F, utskrift av siden og delvis skjermleser-navigasjon, fordi elementene utenfor vinduet slutter å fysisk eksistere i DOM-en. content-visibility løser det samme problemet annerledes: elementene blir værende i DOM-en, nettleseren hopper rett og slett over det kostbare layout- og malingsarbeidet for dem helt til de kommer nær det synlige området – og, overraskende nok, kan den midlertidig avsløre dem når du søker etter tekst i dem.
I artikkelen om tilgjengelighet var en modal med display:none, som fortsatt fantes i tilgjengelighetstreet, et eksempel på en feil som følger av å bygge en modal fra bunnen med div-er. Det egentlige spørsmålet er: hvorfor måtte den i det hele tatt bygges fra bunnen? Jeg går gjennom hva den native <dialog> og popover-attributtet gir deg gratis – top layer, fokusfelle, light dismiss – og hvor disse to mekanismene skiller seg så mye at å forveksle dem er en enkel vei til et utilgjengelig grensesnitt.
«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.
«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.
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.
