Sex kort på ett dashboard, sex spinnrar, och de visas inte tillsammans — de visas ett i taget, som dominobrickor, för varje kort startade bara laddningen efter det ovanför var klart. Det är ett vattenfall, och den totala väntetiden är inte den långsammaste förfrågan, utan summen av alla. use() och Suspense bryter kedjan — men det intressanta är maskineriet under: vad en suspenderad komponent faktiskt kastar, och hur HTML som anländer i fel ordning ändå hamnar på rätt ställe.
I artikeln om mikrointeraktioner skrev jag att transform och opacity animeras på kompositeringstråden, så även en tung sida borde inte hacka en knappanimation. Det stämmer fortfarande – med ett förbehåll som den artikeln teg om: om huvudtråden är blockerad av en lång JS-uppgift kanske animationen aldrig får chansen att starta, eftersom själva klick-handlern väntar i kön. INP är måttet som mäter exakt den luckan – och scheduler.yield() är ett av få sätt att faktiskt stänga den.
En lista med tusen kommentarer renderas långsamt, så du griper efter react-window – och i utbyte mot smidig scrollning förlorar du Ctrl+F, sidutskrift och delvis skärmläsarnavigering, eftersom elementen utanför fönstret helt slutar existera i DOM. content-visibility löser samma problem på ett annat sätt: elementen finns kvar i DOM, webbläsaren hoppar bara över det kostsamma layout- och målningsarbetet för dem tills de hamnar nära det synliga området – och, förvånande nog, kan tillfälligt avslöja dem när du söker efter text i dem.
I artikeln om tillgänglighet var en modal med display:none, som ändå fanns kvar i tillgänglighetsträdet, ett exempel på ett fel som uppstod ur att bygga en modal från grunden med divar. Den verkliga frågan är: varför behövde den överhuvudtaget byggas från grunden? Jag går igenom vad den nativa <dialog> och attributet popover ger dig gratis – top layer, fokusfälla, light dismiss – och var de här två mekanismerna skiljer sig så pass mycket att man med lätthet bygger ett otillgängligt gränssnitt genom att blanda ihop dem.
'Gilla'-knappen reagerar direkt, hjärtat fylls i, räknaren ökar – innan servern ens har svarat. Det är inte samma hastighetsillusion som i artikeln om mikrointeraktioner, det är något som går längre: gränssnittet visar ett tillstånd som ännu inte finns, och antar att det strax kommer att göra det. Jag går igenom hur man bygger det säkert – med en verklig reträtt från lögnen när antagandet visar sig fel, och varför manuell setState plus catch är en sämre version av det useOptimistic ger.
'use server' ser ut som syntaktiskt socker för ett fetch-anrop till en API-route – och just därför behandlar de flesta implementationer det som ett vanligt funktionsanrop. Det är ett misstag med konkreta konsekvenser: varje funktion märkt 'use server' blir en offentlig slutpunkt på nätet, och ett formulär byggt på den här mekanismen fungerar även innan JavaScript hunnit laddas. Jag går igenom vad som faktiskt händer bakom det direktivet, och var fallgroparna finns som inte syns i dokumentationen vid första anblicken.
