import React, { useState, ChangeEvent, useRef } from 'react';
interface User {
id: number;
name: string;
}
export const UserProfile = () => {
// 1. Evităm eroarea de tip dedus ca null permanent
const [user, setUser] = useState<User | null>(null);
const inputRef = useRef<HTMLInputElement>(null);
// 2. Tiparea corectă a evenimentului de input
const handleNameChange = (e: ChangeEvent<HTMLInputElement>) => {
if (user) {
setUser({ ...user, name: e.target.value });
}
};
const focusInput = () => {
// 3. Verificăm opționalul pentru a evita erorile de tip
inputRef.current?.focus();
};
return (
<div>
<input ref={inputRef} type="text" onChange={handleNameChange} />
<button onClick={focusInput}>Focus</button>
<p>Utilizator: {user?.name ?? 'Anonim'}</p>
</div>
);
};Primele zile cu strict: true în tsconfig te fac să vrei să te întorci la Javascript-ul simplu și fără reguli. Am pățit-o acum vreo trei ani când am migrat o aplicație internă cu 14k utilizatori activi de la JS la TS strict. Am vrut să-mi arunc laptopul pe geam în prima zi, dar acum nu aș mai porni niciun proiect fără configurarea asta.
TypeScript strict nu e acolo ca să te încurce, ci ca să te forțeze să gândești cazurile de margine. Hai să vedem cele mai frecvente cinci erori de care te lovești la început în React și cum treci peste ele fără să trișezi cu any.
1. Props fără tip (Implicit any)
Când scrii o componentă simplă și faci destructuring la props direct în argumente, te lovești imediat de eroarea: Binding element 'label' implicitly has an 'any' type.
TS nu știe ce vrei tu să trimiți acolo. Soluția corectă este să definești o interfață. E un pic de boilerplate, dar te salvează când folosești componenta în altă parte, pentru că editorul îți va sugera exact ce props sunt obligatorii.
2. useState cu valoare inițială null
Scrii const [user, setUser] = useState(null) și totul pare în regulă. Când încerci mai târziu să faci setUser({ name: 'Eduard' }), compilerul explodează: Argument of type '...' is not assignable to parameter of type 'null'.
Pentru că ai pus null ca valoare inițială, TS a dedus că starea ta poate fi doar null. Ca să rezolvi asta, trebuie să folosești un tip generic: useState<User | null>(null). Trade-off-ul sincer? Va trebui să pui opționale peste tot prin cod (de exemplu user?.name), dar măcar nu îți mai crapă aplicația în producție cu clasicul Cannot read property of null.
3. Tiparea evenimentelor (onClick, onChange)
Dacă scrii funcția de handler inline, TS e deștept și deduce tipurile. Dar dacă o muți în afara JSX-ului, te lovești de erori de tipare la parametrul e (event).
Nu folosi any aici. React are propriul sistem de evenimente sintetice. Pentru un input de text, tipul corect este React.ChangeEvent<HTMLInputElement>. Sună complicat, dar după ce scrii asta de zece ori, îți intră în reflex.
4. Copiii componentelor (children)
După React 18, tipul React.FC (sau FunctionComponent) nu mai include implicit prop-ul children. Dacă încerci să pui copii într-o componentă custom fără să o declari, vei primi eroare.
Trebuie să adaugi manual children?: React.ReactNode în interfața props-urilor tale. Este un pas în plus, dar elimină bug-urile în care puneai din greșeală copii în componente self-closing.
5. useRef de tip read-only
Când vrei să pui focus pe un input folosind un ref, scrii const inputRef = useRef(null). Când încerci să faci inputRef.current.focus(), TypeScript începe să urle că valoarea este read-only sau că current poate fi null.
Soluția este să specifici elementul HTML exact în generic și să pasezi null ca valoare de pornire: useRef<HTMLInputElement>(null). În plus, înainte de a apela o metodă pe ref, trebuie să verifici mereu dacă inputRef.current există.
Da, TS strict îți mănâncă cam cu 20% mai mult timp la scrierea inițială a codului, mai ales când te luptii cu librării externe prost tipate. Însă timpul ăsta îl recuperezi înzecit la primul refactoring major.
Voi cum ați trecut de faza de frustrare cu TypeScript? Ați fost tentați să folosiți any sau reguli de tip ts-ignore ca să scăpați de erori?