I artiklen om mikrointeraktioner skrev jeg, at transform og opacity animeres på kompositørens tråd, så selv en tung side ikke burde få en knapanimation til at hakke. Det er stadig sandt – med ét forbehold, som den artikel ikke nævnte: hvis hovedtråden er blokeret af en lang JS-opgave, får animationen måske aldrig chancen for at starte, fordi selve klik-handleren venter i kø. INP er den metrik, der måler præcis dette hul – og scheduler.yield() er en af de få måder, man reelt kan lukke det på.
En liste med tusind kommentarer renderer langsomt, så du griber til react-window – og til gengæld for en flydende scroll mister du Ctrl+F, sideudskrift og delvist skærmlæserens navigation, fordi elementer uden for vinduet holder op med at eksistere fysisk i DOM'en. content-visibility løser det samme problem på en anden måde: elementerne bliver i DOM'en, browseren springer bare det dyre layout- og maling-arbejde over for dem, indtil de kommer tæt på det synlige område – og kan overraskende nok midlertidigt afsløre dem, når du søger efter tekst i dem.
I artiklen om tilgængelighed var en modal med display:none, som stadig fandtes i tilgængelighedstræet, et eksempel på en fejl, der opstod ved at bygge en modal fra bunden med divs. Det reelle spørgsmål er: hvorfor skulle den overhovedet bygges fra bunden? Jeg undersøger, hvad det native <dialog>-element og popover-attributten giver dig gratis – top layer, fokusfælde, light dismiss – og hvor de to mekanismer adskiller sig så meget, at det er let at forveksle dem og ende med en utilgængelig grænseflade.
'Synes godt om'-knappen reagerer øjeblikkeligt, hjertet fyldes ud, tælleren stiger – før serveren overhovedet har svaret. Det er ikke den hastighedsillusion fra artiklen om mikrointeraktioner, det er noget mere vidtgående: grænsefladen viser en tilstand, der endnu ikke findes, og går ud fra, at den snart vil gøre det. Jeg undersøger, hvordan man bygger det sikkert – med en reel tilbagerulning, når antagelsen ikke holder – og hvorfor manuel setState plus catch er en dårligere version af det, useOptimistic giver.
'use server' ligner syntaktisk sukker på en fetch til en API-rute – og netop derfor behandler de fleste implementeringer det som et almindeligt funktionskald. Det er en fejl med konkrete konsekvenser: enhver funktion mærket 'use server' bliver et offentligt netværksendepunkt, og en formular bygget på den mekanisme virker, selv før JavaScript når at indlæses. Jeg undersøger, hvad der reelt sker under det direktiv, og hvor faldgruberne ligger, som ikke er indlysende ved første blik i dokumentationen.
Korrekt HTML er kun begyndelsen. Se hvordan tilgængelighedstræet faktisk fungerer, hvorfor ARIA oftere gør skade end gavn end du tror, og byg en rigtig accordion, en live region og Next.js-fokushåndtering sammen med mig.
