import React, { useState, useRef, PropsWithChildren } from 'react';
interface UserCardProps {
name: string;
email?: string;
}
// 1. PropsWithChildren adaugă corect tipul 'children'
export const UserCard = ({ name, email, children }: PropsWithChildren<UserCardProps>) => {
// 2. Generic explicit pentru stare care poate fi null
const [searchTerm, setSearchTerm] = useState<string | null>(null);
// 5. Initializare cu null pentru DOM elements
const inputRef = useRef<HTMLInputElement>(null);
// 3. Tipare explicită pentru evenimentul de onChange
const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
setSearchTerm(e.target.value);
};
return (
<div className="card">
{/* 4. Fallback cu ?? în loc de assertion operator (!) */}
<h2>{name} ({email ?? 'fără email'})</h2>
<input ref={inputRef} onChange={handleChange} />
{children}
</div>
);
};Când am activat prima dată strict: true într-un proiect React de producție (prin 2019, pe o aplicație cu vreo 15k utilizatori zilnici), consola s-a înroșit instant cu peste 120 de erori. M-a apucat groaza, dar după două ore de refactoring m-am prins că 90% din ele erau fix aceleași 5 tipare repetițioase.
Dacă ești la primul proiect de React cu TypeScript strict, garantat te lovești de ele. Hai să le luăm pe rând, scurt și la obiect.
1. Children nu mai vine la pachet în React 18
Înainte de React 18, dacă foloseai React.FC, tipul children era inclus automat. Echipa de la React a scos chestia asta pentru că permitea componente fără copii să primească copii fără ca compilatorul să se plângă.
Acum, când faci un wrapper și încerci să folosești {children}, TypeScript îți dă eroare. Soluția curată este să folosești utilitarul PropsWithChildren din React sau să declari explicit children: React.ReactNode în interfața ta.
2. useState cu null sau array gol (never[])
Dacă scrii const [user, setUser] = useState(null), TS deduce că user va fi null pentru totdeauna. La fel, useState([]) este inferat ca never[], adică un tablou în care nu vei putea adăuga niciodată vreun element.
Trade-off-ul aici e că trebuie să fii mai explicit, chiar dacă scrii puțin mai mult cod. Folosește mereu generice: useState<User | null>(null) sau useState<Item[]>([]).
3. Handler-e de evenimente scoase din JSX
Dacă scrii inline onChange={(e) => setEmail(e.target.value)}, TypeScript ghicește tipul lui e. Însă dacă exReli funcția în afara JSX-ului, primești eroarea că e are tipul any implicit.
Nu pune any doar ca să scapi de eroare! Tipul corect pentru un input de text este React.ChangeEvent<HTMLInputElement>. Pentru submit la formulare, folosești React.FormEvent<HTMLFormElement>. Îți ia 10 secunde să le înveți și primești autocomplete complet pe proprietățile DOM.
4. Nu mai folosi non-null assertion (!)
Când ai un prop opțional user?: User și vrei să-l pasezi mai departe unei componente care cere obligatoriu un string, compilatorul îți spune Type 'undefined' is not assignable to type 'string'.
Tentația e să pui user!.name, spunându-i compilatorului "crede-mă pe cuvânt, nu e undefined". Am văzut 3 crash-uri urâte în producție luna trecută exact din cauza asta, când API-ul a întors null. Folosește mereu fallback-uri reale: user?.name ?? '' sau pune un guard if (!user) return null; înainte de randare.
5. Ref-uri pentru elemente HTML neinițializate
Când creezi o referință pentru un element din DOM cu useRef(), inițializează-l explicit cu null: useRef<HTMLInputElement>(null). Dacă uiți de null, TypeScript presupune că vrei un ref mutabil (ca un simplu stocaj de valoare) și nu te va lăsa să-l legi la atributul ref al tag-ului HTML.
Concluzie
TypeScript strict pare enervant în primele trei zile, dar odată ce-ți creezi aceste 5 reflexe, te salvează de o tonă de bug-uri de runtime. Voi de ce erori de TS vă loviți cel mai des în proiectele voastre?