Interviu React arhitect: granițe și randare

Un interviu de arhitectură frontend verifică felul în care împarți responsabilitățile între browser, server și echipe. React este o parte a soluției. Strategia de randare, accesul la date, livrarea și recuperarea după erori trebuie explicate în același context.

Ce pregătești la acest nivel

Pornește de la performanța măsurată în React. Continuă cu randare, granițe client-server, contracte de date, design system și migrare graduală. Studiul de caz este un catalog public de cursuri cu un panou privat pentru cursant. Propunerile sunt ale exercițiului, nu o promisiune că o singură arhitectură se potrivește tuturor produselor.

Întreabă cine folosește produsul și ce trebuie să fie rapid. Catalogul are nevoie de pagini descoperibile și linkuri stabile. Panoul privat are nevoie de date corecte pentru utilizatorul autentificat și interacțiuni frecvente. Aceleași priorități nu se aplică identic fiecărei rute.

Separă trei concepte de randare

Randarea pe server poate produce HTML înainte ca aplicația să fie interactivă în browser. Hidratarea leagă comportamentul React de HTML-ul produs anterior. React Server Components permit executarea unor componente într-un mediu separat de client și transmiterea rezultatului prin protocolul suportat de infrastructură.

Aceste concepte se pot combina, dar nu sunt sinonime. O componentă client poate participa la prerandarea inițială într-un framework care o suportă. O componentă server nu este locul pentru useState sau handlers de click. Integrarea React Server Components cere suportul unui framework sau al infrastructurii; nu apare automat în orice proiect React. Referință: Server Components.

Propunerea pentru catalog

Pentru paginile publice propunem HTML disponibil devreme, URL-uri stabile și o politică explicită de actualizare a datelor. Izolăm interactivitatea, precum filtrele sau favoritele, în componente client cât mai mici. Datele publice pot avea un cache comun dacă stabilim cum este invalidat când se schimbă prețul sau disponibilitatea.

Nu presupunem că un preț afișat din cache este autoritativ pentru cumpărare. Operația finală recitește și validează pe server regulile relevante. Aceasta este o decizie a sistemului, independentă de biblioteca folosită pentru buton.

Pentru navigare stabilim ce informație aparține URL-ului: de exemplu, filtrul pe categorie și pagina rezultatelor. Starea pur locală, precum deschiderea unui tooltip, poate rămâne în componentă. Datele primite de la server au o politică de încărcare, expirare și revalidare; nu copiem fără motiv întregul cache într-un store global.

Propunerea pentru panoul privat

Serverul verifică identitatea și dreptul de acces la fiecare operație protejată. Ascunderea unei secțiuni în React nu protejează endpointul. Nu trimitem către browser secrete sau câmpuri private doar fiindcă nu le afișăm. Contractul de răspuns include doar datele necesare ecranului.

Cacheul trebuie separat corect între utilizatori. La ieșirea din cont sau schimbarea identității, datele vechi nu trebuie să rămână vizibile pentru altă sesiune. Testăm două conturi și navigarea înapoi, nu doar loginul fericit. Înregistrarea erorilor trebuie să ofere diagnostic fără a colecta inutil date personale.

Granița dintre componente server și client impune restricții asupra valorilor transmise. Nu o descrie simplist ca „orice funcție poate trece prin props” și nici ca „doar JSON”, deoarece protocolul React suportă propriile tipuri. Consultă lista curentă de valori serializabile pentru use client și API-urile frameworkului ales.

Cum livrezi schimbarea

O migrare completă dintr-o singură încercare este greu de evaluat. Alege o rută reprezentativă, măsoară comportamentul inițial și definește criterii pentru erori, accesibilitate și timpii vizibili utilizatorului. Păstrează o cale de revenire și compatibilitatea contractelor în timpul tranziției.

Un design system stabilește comportamentul elementelor comune: focus, stări de eroare, disabled, contrast și tastatură. Organizarea pe echipe pornește de la responsabilități clare. Microfrontendurile pot permite autonomie de livrare, dar adaugă contracte și cost operațional; propune-le numai când contextul le justifică.

Exersează

1. Desenează catalogul, API-ul și panoul privat. Marchează pentru fiecare flux identitatea, datele publice și datele private.
2. Explică scenariul în care un utilizator iese din cont, iar altul intră pe același dispozitiv. Răspunsul trebuie să includă cacheul și istoricul navigării, nu doar tokenul.
3. Scrie o decizie pentru prima rută migrată. Include alternativa păstrării randării existente, costurile, măsurătorile și revenirea dacă apar regresii.

Autoevaluare

Ai un răspuns solid dacă poți justifica strategia pentru fiecare rută, poți localiza autorizarea și poți descrie un rollout verificabil. Arhitectura nu este o listă de biblioteci; este un set de decizii ale căror efecte pot fi urmărite în produs și în operare.

Întrebări frecvente

Toate componentele trebuie să fie server components?

Nu. Interactivitatea cere componente client. Alege granița după date, comportament și suportul infrastructurii.

SSR și Server Components sunt același lucru?

Nu. Primul descrie producerea HTML-ului pe server, iar al doilea un model de componente cu propriul protocol și granițe.

Pot proteja datele doar printr-un route guard React?

Nu. Controlul interfeței ajută experiența utilizatorului, dar serverul trebuie să autorizeze cererile și datele returnate.

Este obligatoriu un store global?

Nu. Decide separat starea din URL, starea locală și datele serverului. Introdu partajarea când există o nevoie clară.

Cum compar două arhitecturi la interviu?

Folosește aceleași cerințe pentru ambele: date, latență, operare, costul migrării și competențele echipei. Declară ce rămâne de măsurat.

Surse și continuare

Documentație React 19 consultată la 12 octombrie 2026. Pentru consistența operațiilor de business, continuă cu Java arhitect: rezervări și evenimente.