eduardweb.
React & TypeScriptÎncepător#typescript#react#frontend#tips

5 erori de TypeScript în React pe care le-am urât la început (și cum scapi de ele)

De Andreea Crăciun, 18 aug. 2026 · 20 vizualizări · 2 like-uri

Postat 18 aug. 2026
typescript
import React, { useState, useRef } from 'react';

type User = { id: string; name: string };

export const UserProfile = () => {
  const [user, setUser] = useState<User | null>(null);
  const inputRef = useRef<HTMLInputElement>(null);

  const handleNameChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    if (!user) return;
    setUser({ ...user, name: e.target.value });
  };

  return (
    <div>
      <input ref={inputRef} value={user?.name ?? ''} onChange={handleNameChange} />
      <button onClick={() => inputRef.current?.focus()}>Focus input</button>
    </div>
  );
};

Când am activat prima dată strict: true într-un proiect React cu vreo 30k linii de cod, ecranul s-a umplut de 240 de erori roșii în terminal. Dacă ești la început cu TypeScript în React, te lovești garantat de aceleași câteva tipare frustrante. Trecem rapid prin ele ca să nu mai pierzi timp căutând pe Stack Overflow.

1. useState inițializat cu null sau array gol

Scrii const [user, setUser] = useState(null) și 3 rânduri mai jos TypeScript urlă când faci user.name. TS a dedus tipul ca null, nu User | null.

La fel pățești la array-uri: const [items, setItems] = useState([]) devine never[], deci nu vei putea adăuga nimic în el.

Rezolvarea e să pasezi tipul generic explicit:

const [user, setUser] = useState<User | null>(null);
const [items, setItems] = useState<Item[]>([]);

2. Tiparea evenimentelor din formulare

Cea mai comună tentație când ai o funcție separată pentru onChange e să trântești un e: any. Funcționează, dar pierzi tot autocomplete-ul pentru e.target.value.

În loc de any, folosește tipurile native din React. Trucul pe care îl folosesc mereu când nu știu tipul pe de rost: scriu funcția inline onChange={(e) => ...}, pun cursorul peste e în VS Code și copiez tipul sugerat.

Pentru un input clasic, tipul exact este React.ChangeEvent<HTMLInputElement>.

3. Props cu children după React 18

Înainte de React 18, React.FC includea children automat. Mulți încă iau template-uri vechi și se miră de ce primesc eroare când pasează componente copil.

Astăzi, cel mai curat este să renunți complet la React.FC și să-ți definești o interfață clară folosind React.ReactNode:

interface CardProps {
  title: string;
  children: React.ReactNode;
}

4. useRef pe elemente de DOM

Ai scris const inputRef = useRef<HTMLInputElement>() și când vrei să faci inputRef.current.focus() primești eroare că proprietatea e undefined sau read-only.

Regula e simplă: dacă referința e legată de un nod DOM prin prop-ul ref, pasează mereu null ca valoare inițială. Altfel, TypeScript crede că vrei un ref mutabil clasic (pentru valori persistente între randări).

5. Indexarea dinamică a unui obiect

Ai un obiect de configurare și vrei să iei o valoare bazată pe un string: const label = STATUS_LABELS[status]. TS aruncă celebra eroare Element implicitly has an 'any' type because type X cannot be used to index type Y.

Trade-off-ul aici: poți folosi Record<StatusType, string> sau keyof typeof STATUS_LABELS. Prima variantă te forțează să acoperi toate cheile din enum sau union, a doua e mai rapidă pentru obiecte statice as const.

TypeScript strict te încetinește în primele două săptămâni, fără discuție. Dar după ce te obișnuiești cu tiparele astea 5, scazi runtime bugs cu peste 50% înainte să ajungă codul în staging.

Care a fost eroarea de tipare din React care ți-a mâncat cel mai mult timp până i-ai dat de cap?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.