Interfața ascunsă în React are nevoie de reguli pentru păstrarea stării

Revenirea la o filă ar trebui uneori să readucă o sarcină neterminată. Revenirea la fișa altui client nu ar trebui să readucă, fără avertisment, alegerile făcute pentru clientul anterior. Componenta Activity din React simplifică păstrarea interfeței, dar produsul are în continuare nevoie de o decizie privind starea care merită păstrată. Locul acestei decizii este în proiectarea navigării, înainte ca echipa să includă ecranele în Activity.

Această retrospectivă din noiembrie 2026 privește React 19.2, lansat la 1 octombrie 2025. Distincția esențială este între păstrarea unei interfețe și menținerea conexiunilor sale externe. Un ecran ascuns poate păstra starea locală în timp ce efectele sale sunt oprite. Tratarea separată a acestor durate de viață îi dă funcționalității un rost clar și scoate la iveală presupuneri pe care montarea obișnuită le putea ascunde.

Ce se păstrează la ascundere

Anunțul lansării definește două moduri. În modul hidden, Activity ascunde componentele descendente, demontează efectele și amână actualizările până când React nu mai are altceva de procesat. În modul visible, afișează componentele descendente, montează efectele și procesează actualizările normal. Acesta este comportamentul istoric discutat aici, fără a-l extinde la toate versiunile React sau la toate mediile de randare.

Documentația Activity, consultată în noiembrie 2026 ca documentație actualizată continuu, explică ascunderea DOM prin display: none, păstrarea stării anterioare a componentelor și randarea cu prioritate redusă când componentele ascunse primesc proprietăți noi. Descrie și refacerea stării DOM, precum textul neterminat dintr-un câmp. Aceste detalii explică utilitatea revenirii la o sarcină întreruptă. Ele nu fac din starea locală un mecanism de stocare durabilă după reîncărcare, eliminarea componentei Activity sau începerea unei sesiuni noi.

Luați ca exemplu ipotetic un editor de comenzi cu o filă pentru detalii și una pentru previzualizare. Păstrarea textului neterminat la schimbarea filelor poate corespunde așteptării utilizatorului. Păstrarea aceluiași editor când se schimbă comanda selectată este o altă decizie. Identitatea înregistrării trebuie să rămână explicită. Vizibilitatea nu poate stabili singură dacă informația introdusă anterior mai aparține sarcinii afișate acum.

Distincția contează și la schimbarea drepturilor de acces. Starea păstrată pe dispozitiv nu dovedește că permisiunea mai este valabilă. Dacă se schimbă contul sau se retrage accesul, aplicația are nevoie de propria regulă de invalidare. Activity nu transformă o decizie anterioară de autorizare într-una actuală. Întrebarea relevantă este ce mai poate face utilizatorul când interfața reapare.

Abonamentele au nevoie de un responsabil

Un efect care se abonează la o sursă externă are nevoie de o operație de curățare care eliberează abonamentul. Activity poate declanșa acest ciclu, dar nu poate inventa o operație de dezabonare absentă. Același principiu se aplică temporizatoarelor sau conexiunilor deținute de componentă. Nu ar trebui să presupuneți că un ecran ascuns a oprit activitatea externă doar fiindcă DOM-ul său nu se mai vede.

Unele operații pot avea motive întemeiate să continue. O conexiune comună mai multor ecrane vizibile poate aparține unui nivel superior componentei Activity, independent de o singură filă. Produsul poate cere ca salvarea unei ciorne să continue după navigare. În fiecare caz, atribuiți deliberat responsabilitatea și precizați ce încheie operația. Păstrarea accidentală a unei resurse active nu ține locul desemnării unui responsabil.

Și tranziția inversă merită atenție. La recrearea efectelor, un abonament poate întâlni date modificate cât timp ecranul era ascuns. Păstrarea unui rând selectat nu dovedește că rândul mai există. Interfața are nevoie de o regulă care pune alegerile păstrate în acord cu cele mai recente date externe. Regula poate păstra ciorna, cerând totodată utilizatorului să rezolve o condiție prealabilă care s-a schimbat.

Acestea sunt obligații de proiectare, nu observații dintr-o aplicație rulată. Articolul nu prezintă un experiment React sau măsurători de performanță. Verificarea ulterioară a echipei ar trebui să urmărească sarcina reală: plecarea și revenirea, schimbarea înregistrării selectate, retragerea accesului și reconectarea după actualizări pierdute. Fiecare verificare ar trebui să aibă un rezultat așteptat scris înainte de implementare, inclusiv informația care ar trebui să dispară.

Compilatorul răspunde altei întrebări

React Compiler 1.0 a fost anunțat la 7 octombrie 2025. Este un instrument folosit la compilare pentru memoizare automată, însoțit de îndrumări pentru adoptare treptată. Apariția sa în aceeași săptămână nu face din Activity o funcționalitate a compilatorului și nici din adoptarea compilatorului o condiție prealabilă pentru alegerea duratei de viață a stării. Optimizarea operațiilor repetate și decizia de a păstra o ciornă după navigare rămân preocupări distincte.

Distincția ajută la delimitarea actualizării. O echipă poate discuta comportamentul Activity la rulare fără să pretindă că a evaluat rezultatul compilatorului. Poate adopta și instrumentele compilatorului fără să schimbe regulile de navigare ale produsului. Respectarea semanticii React rămâne necesară; un instrument de optimizare nu furnizează regula de afaceri absentă despre înregistrarea sau contul căruia îi aparține starea.

Uneori remontarea este alegerea mai bună

Cel mai puternic argument împotriva păstrării este simplitatea. O interacțiune scurtă, fără informații de reținut, poate fi mai ușor de înțeles dacă fiecare vizită începe de la zero. Informațiile sensibile sau selecțiile care devin repede nevalide pot face păstrarea chiar nedorită. Includerea tuturor ecranelor posibile în Activity ar păstra și resurse fără să stabilească dacă utilizatorii beneficiază de starea reținută.

Alegeți păstrarea când revenirea la aceeași sarcină are valoare clară și aplicația poate trata schimbările externe. Alegeți resetarea când o vizită nouă ar trebui să verifice din nou condițiile prealabile. Într-un proiect de software la comandă, consemnați ambele rezultate în cerințele de navigare. Atribuiți apoi fiecărui abonament extern un responsabil și o condiție de încheiere. Activity devine util când produsul poate explica atât ce se păstrează, cât și ce se oprește.