React Server Components — 3 reguli de aur pe care le încalcă toată lumea

RSC e feature-ul care a împărțit cel mai tare comunitatea React. Dar confuzia e tehnică, nu filosofică.

Regula 1: "use client" e UN granița, nu UN fișier

Când pui "use client" la începutul unui fișier, TOT ce e importat din acel tree devine client. Părinții pot fi server. Copiii devin automat client.

Nu pui "use client" "să fie" — pune-l strict unde ai nevoie de state/effects/events.

Regula 2: Server Components NU pot primi functii ca props

<ServerComp onSomething={() => ...} /> — funcția nu e serializabilă, eroare.

Workaround: pasezi date, handler-ul îl pui în componenta client.

Regula 3: Client Components pot primi Server Components ca CHILDREN

Aici e magia. Poți avea:

<ClientModal>
  <ServerContent /> {/* rendered pe server, dar randat dintr-un client */}
</ClientModal>

E pattern-ul care-ți salvează 80% din "trebuie să fac totul client".

Pattern-ul meu preferat

• page.tsx → server, face fetch-urile
• O componenta "shell" client care ține state-ul UI (modal open/close)
• Conținutul paginii tot server, pasat ca children

Hydration mismatch — cum îl previi

90% din cazuri: randezi ceva bazat pe Date.now(), Math.random() sau window la primul render.

Rezolvare:

• Calcul pe server, trimis ca prop stabil
• useEffect pentru lucruri dependente de browser
• suppressHydrationWarning doar pentru timestamp-uri pe care chiar vrei să le lași să difere

Când NU folosesc RSC

• Proiecte mici (sub 20 pagini) unde complexitatea nu merită
• Aplicații 100% autentificate (zero SEO) — Vite e mai simplu

În rest, RSC schimbă fundamental cum gândesc arhitectura. Merită.