import React, { useState } from 'react';
interface User {
id: number;
name: string;
}
export const UserForm = () => {
// Rezolvă eroarea #2 (fără inferență de tip 'never[]')
const [users, setUsers] = useState<User[]>([]);
const [inputValue, setInputValue] = useState('');
// Rezolvă eroarea #3 (typing corect pentru eveniment)
const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
setInputValue(e.target.value);
};
const addUser = () => {
if (!inputValue) return;
setUsers([...users, { id: Date.now(), name: inputValue }]);
setInputValue('');
};
return (
<div>
<input value={inputValue} onChange={handleChange} />
<button onClick={addUser}>Adaugă</button>
</div>
);
};Dacă tocmai ai trecut strict: true în tsconfig.json pe un proiect de React, probabil îți vine să arunci laptopul pe geam. E absolut normal. Am trecut prin asta prin 2019, la un proiect cu vreo 12.000 de useri activi, când am decis să migrăm de la JS chior la TS strict. Ne-am trezit instant cu peste 400 de erori în terminal la primul build.
TypeScript te încetinește enorm în primele două săptămâni, ăsta e adevărul pe care nu-ți-l spune nimeni la interviuri. Scrii mai mult cod de boilerplate și te cerți constant cu compilatorul. Dar trade-off-ul merită din plin: după ce treci de faza asta de frustrare, scapi de 90% din bug-urile stupide de runtime pe care altfel le descopereau clienții în producție.
Hai să vedem cele mai frecvente 5 erori pe care le vei lovi la început și cum le rezolvi corect, fără scurtături murdare.
1. Binding element 'x' implicitly has an 'any' type
Cea mai clasică eroare de început. Scrii o componentă simplă: const Button = ({ label }) => ... și TS începe să urle. În JS mergea brici. În TS strict, compilatorul vrea să știe exact structura obiectului de props.
Rezolvarea este să definești mereu o interfață clară. Nu folosi any doar ca să scapi rapid de eroare, pentru că anulezi tot sensul sistemului de tipuri.
2. Property 'x' does not exist on type 'never'
Asta apare de obicei când folosești un array gol în useState. Dacă scrii const [users, setUsers] = useState([]), TS deduce automat că tipul stării este never[] (adică o listă care va rămâne mereu goală). Când încerci mai târziu să faci setUsers([{ id: 1, name: 'Adi' }]), compilarea crapă.
Trebuie să folosești generics ca să-i spui explicit compilatorului ce va conține lista respectivă: useState<User[]>([]).
3. Parameter 'e' implicitly has an 'any' type la event-uri
Când scrii o funcție inline în JSX, de genul onChange={(e) => setVal(e.target.value)}, TS e destul de deștept să deducă tipul lui e. Dar în momentul în care muți funcția în afara JSX-ului ca să cureți codul, apare eroarea.
Trebuie să tastezi manual tipul evenimentului. Pentru un input de text standard, tipul corect este React.ChangeEvent<HTMLInputElement>.
4. Object is possibly 'null' la useRef
Vrei să pui focus pe un input folosind un ref. Scrii direct inputRef.current.focus(), dar TS te oprește. De ce? Pentru că în momentul inițializării componentei, ref-ul este null (până se randează efectiv DOM-ul).
Cea mai curată rezolvare este să folosești optional chaining: inputRef.current?.focus() sau o simplă verificare if.
5. Type 'undefined' is not assignable to type 'string'
Se întâmplă des când ai un prop opțional în componentă (de exemplu, className?: string) și încerci să-l pasezi mai departe unei alte componente sau funcții care se așteaptă la un string obligatoriu.
Soluția este să oferi o valoare de fallback direct la destructurare sau în apel: className = ''.
La final, un sfat de veteran: nu trișa cu as any sau cu comentarii de tipul // @ts-ignore. Pare o scurtătură bună când ești în criză de timp, dar peste 6 luni o să uiți de ce ai pus-o și o să te trezești cu crash-uri ciudate în producție.
Voi cum ați trecut peste primul impact cu TypeScript în React? V-a venit și vouă să-i dați disable în prima zi?