Seks kort på et dashbord, seks spinnere, og de vises ikke sammen — de vises én etter én, som dominobrikker, fordi hver enkelt bare begynte å laste etter at den ovenfor var ferdig. Det er et fossfall, og den totale ventetiden er ikke den tregeste forespørselen, men summen av alle. use() og Suspense bryter kjeden — men det interessante er maskineriet under: hva en suspendert komponent faktisk kaster, og hvordan HTML som ankommer i feil rekkefølge likevel lander på rett sted.
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.
