interface UserProps {
name: string;
age: number;
onUpdate: (id: string) => void;
}
const UserProfile = ({ name, age, onUpdate }: UserProps) => {
const inputRef = useRef<HTMLInputElement>(null);
const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
console.log(e.target.value);
};
return (
<div ref={inputRef}>
<h1>{name} ({age})</h1>
<input type="text" onChange={handleChange} />
</div>
);
};Am observat că majoritatea developerilor care vin de pe React (JavaScript) și fac pasul spre TypeScript au tendința să vadă compilatorul ca pe un inamic care le strică flow-ul. La un proiect recent, un magazin online cu vreo 15 ecrane, am preluat codul de la un junior care se săturase de erori roșii în VS Code și pusese any la aproape 40% din variabile. Rezultatul? Runtime errors peste tot, exact ce trebuia să evite TS.
Nu ești tu de vină, e doar o schimbare de paradigmă. Dacă activezi strict: true în tsconfig.json (ceea ce îți recomand cu tărie), te vei lovi de câteva ziduri specifice. Iată cum le dărâmi.
Problema clasică: Tiparea Props-urilor
Cea mai frecventă eroare apare când încerci să deconstruiești props-urile într-un component și TS urlă că nu știe ce e { title }. Mulți sunt tentați să folosească React.FC, dar eu m-am convins de-a lungul timpului că e mai curat să tipărești direct argumentele funcției. React.FC vine cu niște limitări la children (în versiunile vechi) și face genericele mai greu de citit.
Am pățit să stau 20 de minute să înțeleg de ce un component nu acceptă children, doar ca să realizez că tipul implicit din FC se schimbase între versiuni de React. Definește o interfață clară și pasează-o funcției direct. E mult mai predictibil.
Evenimentele din Formulare
Ăsta e momentul în care mulți cedează și bagă e: any. Când scrii un onChange, TS nu știe dacă e.target este un input, un select sau un buton. Soluția corectă este React.ChangeEvent<HTMLInputElement>. Da, e lung de scris, dar îți oferă autocompletare pentru value sau checked imediat. Trade-off-ul e un pic de zgomot vizual pentru o siguranță mult mai mare la refactoring. Dacă schimbi inputul cu un textarea, compilatorul îți va spune imediat că tipul nu se mai potrivește.
useRef și obsesia pentru null
useRef dă cele mai multe bătăi de cap pentru că, prin definiție, un ref la un element DOM începe ca null. Dacă scrii useRef<HTMLDivElement>(), vei vedea că myRef.current este opțional. Eroarea clasică este să încerci să accesezi myRef.current.style fără să verifici dacă există.
Întotdeauna inițializează cu null: useRef<HTMLDivElement>(null). Așa, TS te forțează să pui un if (myRef.current) înainte să faci ceva cu el. Pare un pas extra, dar am scutit zeci de erori de tip "Cannot read property of null" în producție doar cu regula asta simplă.
State-ul pentru obiecte sau array-uri
La primitive, TS se prinde singur: useState(0) știe că e number. Dar la un array de obiecte care vine dintr-un API, implicit va fi un array gol de tip never[]. Aici e obligatoriu să folosești generice: useState<User[]>( []).
Am avut un caz unde am economisit cam 30% din timpul de debugging la un dashboard complex pentru că am definit interfețele pentru datele din API încă din prima zi. Când backend-ul a schimbat user_id în id, am avut 12 erori de compilare instant. Le-am rezolvat în 2 minute. Fără TS, aflam probabil de la clienți că nu se mai încarcă profilele.
Concluzia despre Trade-offs
TypeScript în React nu e despre a scrie mai mult cod, ci despre a scrie cod pe care te poți baza. Da, viteza de scriere scade cu vreo 15-20% la început, mai ales când te lupți cu tipurile pentru librării externe. Dar timpul ăla îl recuperezi înzecit când faci refactoring sau când un coleg nou trebuie să înțeleagă ce face componentul tău.
Tu de care eroare de TS te-ai lovit cel mai des și te-a făcut să vrei să dai delete la node_modules?