Ce trebuie să știi înainte de React: verifică-te după listă

28 august 2026 · 8 minute · Dediu Pavel

Sfatul «învață mai întâi JavaScript» este inutil fără un criteriu al suficienței. Mai jos este o listă concretă: ce trebuie să ai în mână înainte de React, ce poți să nu știi și în ce ordine mergi mai departe.

Răspunsul scurt: de ce «React fără HTML și CSS» nu există

React nu înlocuiește HTML și CSS, ci le generează. O componentă este o funcție care returnează o descriere a structurii; în browser ajung, în final, aceleași taguri și aceleași clase. Dacă nu înțelegi de ce s-a deplasat un bloc, nici în React nu vei înțelege — doar că acum, între tine și structură, va mai fi și un bundler.

În al doilea rând: React nu rezolvă problemele de layout. În interiorul componentei tot ai nevoie de flex și grid, de stările butonului, de ordinea focusului, de comportamentul pe un ecran îngust. Niciun hook nu face nimic din toate acestea.

Cum arată asta în practică: omul fără bază se blochează nu la React, ci la limbaj — și nu își dă seama. Eroarea «Rendered fewer hooks than expected» se citește ca o problemă a framework-ului, dar înseamnă un return timpuriu, deasupra apelului unui hook. O randare infinită pare un capriciu al React, dar de fapt este un obiect creat în corpul componentei, care a ajuns în dependențe. Fără bază, astfel de lucruri se depanează pe ghicite; cu bază — într-un minut.

Și al treilea lucru, cel mai neplăcut pentru cei care vor să sară peste etape: fără JavaScript de bază, React arată ca un set de descântece. Array-urile, obiectele, referințele, promisiunile nu sunt un «supliment», ci materialul din care este făcută orice componentă. Cine nu înțelege diferența dintre copia unui obiect și referința la el va vâna săptămâni întregi eroarea «am schimbat starea, iar ecranul a rămas la fel».

Ce din HTML și CSS este obligatoriu și de ce anume asta

Lista este mai scurtă decât pare, iar fiecare punct din ea se amortizează imediat.

Taguri semantice. Trebuie să poți alege între section, article, button și div. În React, tentația de a construi totul din div cu un handler de clic este deosebit de mare, în timp ce un buton adevărat îți oferă gratuit focusul de la tastatură și declanșarea cu Enter.

Modelul de cutie și fluxul. De ce un bloc a primit exact acele dimensiuni, ce face box-sizing: border-box, de unde apare derularea orizontală. Sunt exact aceleași întrebări ca fără React, doar că depanarea lor într-un arbore de componente este mai grea. Dacă tema ți se pare nesigură, începe cu analiza de ce blocul este mai lat decât ai stabilit.

Flexbox și Grid. Nu proprietățile pe de rost, ci capacitatea de a alege: rând sau tabel, cine distribuie spațiul liber. În React, codul catalogului trăiește într-un fișier CSS și nu dispare nicăieri.

Stări și un minimum de accesibilitate. :hover, :focus-visible, disabled, inelul vizibil de focus, legătura dintre label și câmp. Formularele sunt al doilea modul ca volum al oricărui proiect React, iar toate acestea se cer acolo imediat.

Criteriul «știu HTML și CSS» merită formulat nu printr-o listă de teme, ci printr-un rezultat: iei macheta altcuiva și o reproduci fără ajustări din ochi, iar la întrebarea «de ce are blocul acesta lățimea asta» răspunzi printr-un calcul, nu ridicând din umeri. Dacă până acolo mai e mult, React nu va grăbi nimic.

Ce poți să nu știi: animațiile, preprocesoarele, CSS-in-JS, subtilitățile fonturilor. Se adună mai târziu și într-o seară.

Ce din JavaScript îți trebuie: destructurare, map, promisiuni, async/await, module

Nici aici nu este «tot limbajul». Îți trebuie setul care apare în fiecare a doua componentă.

Destructurarea. Scrierea function Card({ product }) este exact ea, iar props-urile fără ea se citesc greu. Plus destructurarea unui array: const [value, setValue] = useState(1) este o destructurare obișnuită de array, nu magia unui hook.

Metodele array-urilor. map pentru randarea unei liste, filter pentru filtrarea catalogului, find, some, reduce pentru totalul coșului. Esențial este că ele returnează un array nou și nu îl modifică pe cel inițial.

Copierea prin spread. { ...order, qty: 2 } și [...items, product]. În React, starea se actualizează doar cu o valoare nouă: push și atribuirea într-un câmp modifică obiectul pe loc, referința rămâne aceeași, React compară prin Object.is, vede o potrivire și sare peste randare.

Funcții și closure-uri. Funcțiile săgeată, funcția ca argument, înțelegerea faptului că o funcție creată în corpul componentei este de fiecare dată alta. Fără asta este imposibil să te descurci cu dependențele unui efect.

Promisiuni, async/await și fetch. O cerere către server, așteptarea răspunsului, tratarea erorii. Plus try/catch și JSON.parse.

Module. import și export, diferența dintre exportul implicit și cel cu nume. Un proiect React înseamnă două-trei zeci de fișiere, legate prin importuri.

Ce din JavaScript poți să nu știi înainte de start: prototipurile și this, clasele, generatoarele, lucrul cu datele calendaristice, expresiile regulate, subtilitățile buclei de evenimente. Asta nu înseamnă că nu sunt necesare niciodată — înseamnă că, până la prima componentă, nu îți vor trebui nici măcar o dată.

Expresii versus instrucțiuni. Operatorul ternar și && în locul lui if în interiorul structurii. Nu este o chestiune de stil: în structură se substituie o valoare, iar if nu are valoare.

Listă de autoverificare: șapte sarcini pe care trebuie să le poți rezolva

Criteriul este simplu: faci fiecare sarcină singur, fără o soluție gata în fața ochilor, și poți explica fiecare rând. Timpul pentru toate șapte este o seară.

• Să construiești un rând de carduri care, pe un ecran îngust, se rearanjează într-o singură coloană, și să explici de ce ai ales flex sau grid.
• Să găsești în pagina altcuiva cauza derulării orizontale și să o repari fără a încerca procente.
• Să scrii o funcție care primește un array de produse și returnează un array nou, doar cu produsele mai ieftine de 30, sortate după preț; array-ul inițial rămâne neschimbat după apel.
• Să obții o copie a unui obiect cu un câmp modificat și să explici prin ce se deosebește asta de order.qty++.
• Să încarci date dintr-un API public prin fetch și async/await, să afișezi lista, să arăți un mesaj de eroare la căderea rețelei și un indicator în timpul încărcării — în JavaScript pur, fără biblioteci.
• Să atașezi un handler de eveniment pe document, să îl scoți și să explici de ce trebuie scos.
• Să împarți codul în două fișiere, să exporți o funcție din unul și să o imporți în celălalt, și să rulezi asta în browser.

Ce faci cu rezultatul listei de verificare

Verifică-te cinstit: fără o soluție gata în fila alăturată, fără sugestii de la o rețea neuronală, din prima încercare. O sarcină este considerată rezolvată dacă poți explica cu voce tare de ce există fiecare rând din ea și dacă o poți repara atunci când se strică. Altfel, nu este o competență, ci o recunoaștere.

Ai trecut toate șapte — poți începe React, iar lunile următoare se vor duce pe învățarea gândirii prin stare, nu pe lupta cu limbajul.

Te-ai blocat la primele două — ai nevoie nu de React, ci de HTML și CSS: «HTML și CSS fără magie» acoperă fluxul, modelul de cutie, flex, grid, responsivitatea și formularele. Nu este «un pas înapoi», ci drumul scurt: aceleași teme vor trebui parcurse oricum, doar că în interiorul React vor costa mai mult.

Ai trecut de partea de HTML și CSS, dar te-ai împiedicat de sarcinile de la a treia la a șaptea — adună JavaScript punctual, după lista de mai sus, nu «tot limbajul de la început».

Dacă lista este trecută în întregime, mai departe se potrivește cursul «React în practică» — 26 de ore, iar cerința de intrare este scrisă exact așa: necesită HTML/CSS. El începe cu construirea proiectului pe Vite și cu împărțirea machetei catalogului în componente și se termină cu un magazin cu coș, plată și publicare online — adică exact cu sarcinile pentru care se ia React.

Ce NU trebuie să știi (și pe ce pierd începătorii luni degeaba)

TypeScript. Este util, dar adaugă un al doilea limbaj peste unul necunoscut. Ia-l după două-trei proiecte în JavaScript.

Redux și alți manageri de stare. În React-ul modern, locul lor este luat de useState, context și useReducer; un store extern are sens atunci când vei simți cu mâna ta ce lipsește.

Next.js și randarea pe server. Un instrument separat, cu regulile lui. Să îl înveți în locul React-ului înseamnă o harababură garantată.

Componente pe clase și metodele ciclului de viață. Ele au rămas în codul vechi și nu sunt o temă pentru început.

Configurarea webpack și Babel. Vite face build-ul cu o singură comandă. Configurarea unui bundler este o sarcină care apare peste un an, dacă apare.

Algoritmi și probleme de la interviuri. Nu au nicio legătură cu capacitatea de a construi o interfață.

Testare, șabloane, arhitectură. Toate acestea se așază pe experiență. Pe teren gol, ele devin reguli fără motive.

De ce nu merită să începi copiind un proiect mare de pe YouTube

Un clip de zece ore, «facem un marketplace în React», dă senzația de progres și aproape zero competență. Cauza este mecanică: tu repeți un set de caractere, iar deciziile le ia autorul. La final ai un proiect funcțional și nicio eroare găsită de tine — iar tocmai căutarea erorilor este munca de bază.

Te poți verifica astfel: oprește clipul înainte de o modificare și prezice ce se va întâmpla pe ecran. Ai ghicit — înțelegi materialul. Nu ai ghicit — te uiți la un film.

Al doilea semn al aceluiași lucru: după clip poți repeta proiectul, dar nu poți adăuga în el o funcție nouă, care nu era în video. Adaugă la catalogul altcuiva sortarea după preț — și se va vedea unde se termină copia și unde începe înțelegerea.

Înlocuitorul care funcționează: sarcini mici, pe care ți le formulezi singur, plus defecțiuni intenționate. Ai construit un contor de cantitate — strică-l: adună doi prin două apeluri consecutive ale setterului și vezi de ce se adaugă doar unu. Ai scris un efect cu o abonare — scoate funcția de curățare și vezi cum, după cinci deschideri ale ferestrei modale, Escape se declanșează de cinci ori. Astfel de defecțiuni se rețin mai bine decât orice explicație, pentru că vezi singur cauza și efectul.

Ordinea temelor în interiorul React-ului

Succesiunea în care temele nu se încurcă între ele arată astfel: construirea proiectului și JSX; componente și props; starea prin useState; liste, chei și randare condiționată; formulare și validare; efecte și încărcarea datelor de la server; stările de încărcare și de eroare; rutare; starea comună — context și useReducer; performanță și randări inutile; teste; build și deploy.

Două locuri în care se împiedică aproape toți. Primul este useEffect: el este luat drept «fă ceva după randare» și lumea începe să calculeze în el date derivate. Lista filtrată și totalul comenzii se calculează direct în corpul componentei, iar efectul este necesar pentru sincronizarea cu lumea exterioară — titlul filei, un ascultător de tastatură, un temporizator, o cerere.

Al doilea sunt dependențele efectului. React le compară prin Object.is: primitivele după valoare, iar obiectele, array-urile și funcțiile după referință. Un obiect creat direct în corpul componentei este nou la fiecare randare, comparația eșuează, iar efectul pornește iar și iar. De aici cresc majoritatea buclelor infinite, iar înțelegerea referințelor din lista de verificare se amortizează exact aici.

Ca timp, reperul este acesta: dacă partea de HTML și CSS este deja sigură, până la prima aplicație proprie, cu date și rute, sunt aproximativ două-trei luni de studiu regulat. Promisiunile de tipul «React în două săptămâni» înseamnă, de obicei, că HTML, CSS și JavaScript nu sunt incluse în acest termen.

Separat, merită știut dinainte: în modul de dezvoltare, React montează componenta de două ori, așa că efectul se execută de două ori. Nu este un bug și nu este un motiv să scoți StrictMode — este o verificare a faptului că efectul tău curăță corect după el.

React, Vue sau altceva: răspunsul scurt și onest

Pentru un începător, diferența dintre ele este mai mică decât diferența dintre «știu HTML și CSS» și «nu știu». Componente, props, stare, liste cu chei, efecte — există peste tot, iar al doilea framework, după primul, se învață în câteva săptămâni.

Criteriul practic este unul singur: uită-te la vreo zece anunțuri de angajare la care chiar ai aplica și ia ceea ce apare mai des acolo. De obicei este React, dar în orașul sau în nișa ta poate fi altfel.

Același răspuns este valabil și pentru «stack-ul la modă». Vue, Svelte, Solid, Angular schimbă sintaxa și setul de convenții, dar nu schimbă sarcinile: să împarți interfața în părți, să păstrezi starea într-un singur loc, să arăți încărcarea și eroarea, să nu strici layout-ul pe un ecran îngust. Toate acestea se transferă între instrumente aproape fără pierderi, în timp ce golurile din HTML, CSS și din limbaj nu se transferă nicăieri.

Și nu schimba instrumentul până nu duci la capăt două-trei proiecte proprii. Schimbarea instrumentului aproape întotdeauna mută momentul în care devine greu, nu îl elimină: va fi greu exact în același loc — la stare, la datele de la server și la cazurile-limită.