React Suspense: porniți cererile înainte ca afișarea să aibă nevoie de ele

După actualizarea unui cadru de dezvoltare, toate verificările privind conținutul unei pagini pot trece, iar pagina să fie totuși mai lentă. Discuția despre React Suspense din iunie 2024 a arătat cum se poate ajunge aici: cereri independente, care porneau împreună, puteau ajunge să pornească succesiv. Concluzia pentru arhitectura aplicației este să stabiliți explicit când începe încărcarea datelor, fără să depindeți de ordinea în care React ajunge la componentele de același nivel.

Nu trebuie să mutați toate interogările într-o componentă părinte uriașă. Păstrați cerințele de date aproape de componentele care le cunosc. O rută, un mecanism de încărcare sau unul de preîncărcare poate răspunde de pornirea la timp a operațiilor independente. Locul în care datele sunt folosite și momentul în care sunt cerute sunt decizii diferite.

Ce a arătat problema semnalată în iunie

Problema React #29898, deschisă pe 14 iunie 2024, descria o modificare din versiunea preliminară React 19: după suspendarea unei componente, React nu mai continua evaluarea anticipată a componentelor de același nivel în acea încercare. Dacă cererile erau descoperite abia când începea evaluarea acelor componente, se schimba momentul pornirii lor. Demonstrația unui participant din acea discuție nu este o măsurătoare valabilă pentru toate aplicațiile React.

Suspense vă poate face să citiți arborele componentelor ca pe un plan al cererilor de rețea. Așezați mai multe panouri sub aceeași limită Suspense, fiecare citește date și vă așteptați ca React să descopere toate cererile. Așteptarea ascunde o presupunere: React trebuie să continue evaluarea componentelor după întâlnirea uneia pe care nu o poate termina. Schimbarea acestui comportament poate modifica așteptarea utilizatorului, fără să schimbe conținutul final.

Discuția din iunie privea o versiune candidată la lansare. Privind retrospectiv din noiembrie 2026, anunțul versiunii stabile este datat 5 decembrie 2024. Ghidul de actualizare indicat de anunț, citit în forma actuală, descrie afișarea imediată a conținutului provizoriu, urmată de programarea unei alte evaluări a componentelor suspendate de același nivel, pentru a le pregăti. Acest comportament ulterior nu era o funcționalitate disponibilă în iunie și nu garantează eliminarea tuturor cererilor succesive.

Stabiliți dependențele înainte să alegeți gruparea componentelor

Luați un exemplu ilustrativ: pagina unui client afișează datele contului, facturile recente și istoricul solicitărilor de asistență. Presupuneți că toate cele trei cereri au nevoie doar de identificatorul clientului, deja cunoscut din rută. Între ele nu există o dependență impusă de activitatea firmei. Dacă facturile așteaptă datele contului, implementarea a introdus o dependență accidentală.

Schimbați acum exemplul. Pentru istoricul solicitărilor este necesar un token de autorizare primit în răspunsul despre cont. Ordinea este justificată. Pornirea cererii mai devreme poate fi imposibilă sau poate ocoli o etapă necesară de autorizare. Separați operațiile independente de cele ale căror date de intrare nu sunt încă disponibile.

Notați această diferență înainte să modificați JSX. Porniți cererile independente prin mecanismul de încărcare oferit de biblioteca de date sau de cadrul folosit. Fiecare panou poate apoi citi rezultatul din cache ori dintr-o resursă stabilă. Nu construiți un cache propriu pentru promisiuni doar ca exemplul să pară mai scurt. Identitatea cererilor, durata lor de viață și recuperarea după erori cer decizii explicite.

Nici mutarea cererilor într-un loader nu ajunge dacă acesta așteaptă fiecare răspuns înainte să pornească următoarea cerere independentă. Căutați suprapunerea operațiilor acolo unde dependențele o permit. Directorul în care se află codul nu dovedește această proprietate.

Includeți comportamentul rețelei în verificarea actualizării

La o actualizare, merită să verificați atât corectitudinea informațiilor afișate, cât și pornirea independentă a operațiilor care nu depind unele de altele. Acestea sunt recomandări pentru verificarea aplicației proprii. Pentru acest articol nu au fost executate exemple React și nici experimente de performanță.

Alegeți un parcurs important pentru firmă, de exemplu deschiderea unui cont înainte de încasarea unei plăți. Comparați versiunea existentă cu cea propusă, întâi fără date în cache, apoi în condițiile obișnuite ale utilizatorilor. Înregistrați ordinea pornirii cererilor, nu doar momentul încheierii lor. Cache-ul poate ascunde pornirea întârziată; un server neobișnuit de lent poate domina ambele măsurători.

Păstrați condițiile comparabile. Modul de dezvoltare, generarea paginii pe server, navigarea în browser și versiunea de producție nu descoperă neapărat operațiile în același fel. Verificați traseul urmat efectiv de utilizatori și păstrați suficiente informații ca să distingeți o dependență nouă de variațiile obișnuite ale rețelei. O captură cu pagina finală nu poate arăta această diferență.

Evitați o regulă fragilă care cere ca toate operațiile să înceapă într-un număr arbitrar de milisecunde. Verificați relația relevantă, dacă instrumentele permit, și investigați modificările semnificative dintr-o înregistrare reprezentativă. Problema firmei este timpul pierdut pe un parcurs important, nu câștigarea unei comparații artificiale.

Păstrarea cerințelor lângă componente are motive bune

Obiecția cea mai puternică este că încărcarea la nivelul rutei poate îngreuna refolosirea componentelor. Părintele trebuie să știe ce componente vor apărea, panourile opționale pot provoca cereri inutile, iar loaderul central poate deveni o a doua descriere a interfeței.

Aceste costuri sunt reale. Pentru un panou deschis rar, poate fi mai bine să cereți datele abia când utilizatorul îl solicită. Într-o aplicație mică, cu răspunsuri rapide din cache, reorganizarea poate costa mai mult decât întârzierea eliminată. Și limitele Suspense au un rol vizual: trebuie să reflecte ce poate folosi utilizatorul separat.

Păstrați cerințele lângă componente unde ajută. Separați definirea interogării de pornirea ei, folosiți mecanismele de preîncărcare acceptate și măsurați înainte să reorganizați o aplicație funcțională. Recomandarea are o limită clară: eliminați ordinea accidentală când produce întârzieri relevante, mai ales dacă o actualizare o scoate la iveală.

Într-un plan de mentenanță software, acesta este un criteriu concret de acceptare. Actualizarea este terminată când parcursul important rămâne corect, iar comportamentul cererilor este înțeles. Evaluarea componentelor trebuie să urmeze un plan intenționat de încărcare a datelor, fără să devină, pe ascuns, singurul plan al aplicației.