React Server Components în producție: patterns pentru SaaS modern

01Modelul mental: server-first, client doar la nevoie

Cea mai importantă schimbare de mindset când lucrezi cu RSC este să tratezi componenta server ca pe alegerea implicită, nu ca pe o excepție. Orice componentă care nu are nevoie de state, evenimente sau API-uri de browser ar trebui să fie server. Asta înseamnă liste, layout-uri, secțiuni de marketing, dashboard-uri preponderent read-only. Doar acolo unde ai nevoie de useState, useEffect sau de listener-i pe DOM marchezi cu use client.

Avantajul este că majoritatea logicii de data fetching dispare din client. Nu mai ai nevoie de React Query pentru date care nu se schimbă des, pentru că poți face fetch direct în componenta server, cu acces la cookies pentru autentificare. Bundle-ul JavaScript scade dramatic pe rute care înainte aveau provider-i și hooks-uri în plus.

Capcana este să forțezi totul ca server component. Componentele puternic interactive, formulare complexe, editoare rich text sau date-pickere trebuie să rămână client. Încercarea de a le împărți excesiv produce cod fragil și greu de mentenat.

• →Server pentru: layout, liste, detalii statice, dashboard read.
• →Client pentru: formulare complexe, animații, editoare, drag-and-drop.
• →Hibrid: shell server, insulă client doar unde e nevoie de interactivitate.
• →Niciodată: client component care primește prop din server doar ca să facă fetch din nou.

02Data fetching: direct în componentă, nu în provider

În SaaS-urile pe care le-am construit la Blackbone, regula este simplă: dacă datele sunt nevoie pentru randare inițială, fetch-ul se face în componenta server, nu într-un provider de client. Asta elimină starea intermediară de loading pentru date care oricum vor fi disponibile la primul render, reduce numărul de roundtrip-uri și face codul mai liniar.

Pentru deduplicare pe aceeași request, React-cache și Cache Components din Next.js 16 fac munca grea. Dacă două componente server din arborele aceleiași pagini cer aceeași listă de utilizatori, se face un singur query către DB. Asta era greu de făcut elegant cu React Query la nivel de client.

Pentru date care se schimbă des, server actions și revalidatePath sau revalidateTag sunt soluția elegantă. Utilizatorul declanșează o acțiune, server-ul mutează datele, iar UI-ul este reîmprospătat fără să fie nevoie de un round trip suplimentar pentru refetch manual.

03Server actions: mai mult decât form submit

Server actions sunt una dintre cele mai subevaluate funcționalități ale stack-ului modern. La prima vedere par doar o modalitate elegantă de a face submit la formulare, dar sunt mult mai mult: îți permit să rulezi cod server din interiorul oricărei componente client, cu type safety end-to-end și fără să scrii endpoint manual.

În proiectele Blackbone le folosim pentru CRUD-uri rapide, pentru toggle-uri de stare, pentru export-uri și pentru integrări cu API-uri terțe. Beneficiul cel mai mare este că nu mai trebuie să întreținem un strat de tRPC sau de REST doar pentru actions simple, ceea ce reduce semnificativ codul boilerplate.

Totuși, server actions nu sunt potrivite pentru tot. Pentru endpointuri publice consumate de aplicații mobile sau de partener integrations, un API REST sau GraphQL clasic este alegerea corectă. Server actions sunt optimizate pentru consum din același frontend, nu pentru contracte publice.

04Client islands: granițele care contează

Pattern-ul client islands înseamnă să încadrezi zonele interactive în componente client mici, ancorate într-un arbore de server components. Practic, pagina rămâne în mare parte server, dar are zone clientside acolo unde ai nevoie de interactivitate: meniuri, modale, filtre, charts interactive.

Beneficiul cheie este că JavaScript-ul trimis la client este doar cât are nevoie insula. Restul paginii rămâne în HTML pur, fără hidratare. Pentru SaaS-uri unde mare parte din ecran este afișare de date, asta înseamnă bundle-uri de zeci de kilobytes în loc de sute, ceea ce se traduce în INP și TBT mult mai bune.

Pattern-ul are însă o capcană: prop-urile pasate de la server la client trebuie să fie serializabile. Nu poți pasa funcții sau instanțe de clase. Asta forțează o disciplină utilă: la granița server-client, datele sunt simple și explicite, nu obiecte cu metode.

• →Insulă mică, scop clar, una pe zonă interactivă.
• →Prop-uri serializabile: stringuri, numere, obiecte plain.
• →State local în insulă, nu împrăștiat în mai multe componente.
• →Server actions pentru operații care necesită server.

05Când NU folosești React Server Components

Există situații în care RSC este alegerea greșită. Prima este aplicațiile preponderent interactive, cum sunt editoarele colaborative, dashboard-urile cu live updates dense sau aplicațiile tip Figma. Acolo, fiecare interacțiune produce schimbare de UI, iar overhead-ul de round trip la server pentru re-render anulează beneficiile RSC.

A doua situație este când ai un backend deja consolidat, separat de frontend, care expune un API REST sau GraphQL bine documentat. Acolo, beneficiul de a face fetch direct din server component este mic, pentru că oricum apelezi un API extern. Codul devine doar un proxy obositor, iar SPA clasic cu React Query poate fi alegerea mai sănătoasă.

A treia situație este pentru proiecte mici, cu o singură pagină interactivă. Adoptarea RSC vine cu un cost de complexitate inițială: trebuie să înțelegi granițele, server actions, caching. Pentru un site simplu, această curbă nu se justifică.

06Antipatterns frecvente și cum le eviți

Cel mai frecvent antipattern este folosirea greșită a use client la nivel de root. Ai pus o singură variabilă de state într-un layout și ai marcat tot fișierul ca use client. Rezultatul: tot ce este sub layout devine client, iar beneficiile RSC dispar. Soluția este să muți doar zona cu state într-o componentă mică, separat.

Un alt antipattern este să pasezi date mari de la server la client doar pentru afișare. Dacă o componentă afișează un tabel cu 500 de rânduri, nu are sens să trimiți 500 de obiecte JSON serializate. Fă tabelul server component și păstrează doar interacțiunile în client.

Al treilea antipattern, foarte comun, este să nu folosești revalidateTag și să forțezi reîncărcare totală a paginii după fiecare mutație. Pierzi tot beneficiul cache-ului. Echipa Blackbone insistă în code review pe granularitate clară a tag-urilor de cache, exact pentru a evita această capcană.