import React, { useState, useRef } from 'react';
interface CardProps {
title: string;
children: React.ReactNode; // React 18 cere asta explicit
}
interface User {
id: number;
name: string;
}
export const UserCard = ({ title, children }: CardProps) => {
const [users, setUsers] = useState<User[]>([]); // Evită tipul "never"
const inputRef = useRef<HTMLInputElement>(null);
const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
console.log(e.target.value);
};
return (
<div>
<h2>{title}</h2>
{children}
<input ref={inputRef} onChange={handleChange} />
<button onClick={() => inputRef.current?.focus()}>Focus</button>
</div>
);
};Trecerea la TypeScript strict în React e ca dușul rece de dimineață: doare la început, dar te trezește repede. Dacă te-ai lovit de un ecran plin de erori roșii la primul tău proiect, stai liniștit, toți am trecut prin asta. Hai să vedem cele mai frecvente 5 erori pe care le-am tot reparat în proiectele echipei și cum le rezolvi corect.
1. Implicit any pe props
Cea mai clasică eroare apare când scrii o componentă simplă și pasezi proprietăți fără să le definești tipul. TS nu știe ce vrei tu să pui acolo și blochează build-ul.
Trade-off-ul: Da, să scrii interfețe pentru absolut fiecare componentă mică înseamnă mai mult boilerplate și timp pierdut în faza de prototipare. Totuși, când codul crește, te ajută enorm la refactoring.
Soluția este să definești un interface clar pentru props. Nu folosi any doar ca să scapi de eroare, fiindcă anulezi tot sensul sistemului de tipuri.
2. useState([]) devine array de tip never
Am pățit asta la un dashboard cu 8k useri activi, unde aduceam o listă de clienți dintr-un API. Scrii const [users, setUsers] = useState([]) și când vrei să faci setUsers(dataFromAPI), compilerul îți dă o eroare bizară despre tipul never[].
Pentru că ai inițializat starea cu un array gol, TypeScript presupune că acel array va rămâne mereu gol. Ca să rezolvi asta, folosește generics: useState<User[]>( []). Astfel, TS știe exact ce structură vor avea datele care vin ulterior din rețea.
3. Dispariția lui children din React.FC
Dacă ai învățat React acum câțiva ani, probabil foloseai tipul React.FC pentru componente. Începând cu React 18, echipa a scos proprietatea children din definiția implicită a lui FC. Multe proiecte vechi s-au spart la upgrade din cauza asta.
Acum trebuie să declari explicit children în interfața ta de props ca fiind React.ReactNode. E un pas în plus, dar e mult mai sigur, deoarece nu toate componentele ar trebui să accepte elemente copii.
4. Evenimentele din formulare (e: any)
Când pui un handler pe un <input> direct inline, de tipul onChange={e => setValue(e.target.value)}, totul merge uns. Dar în momentul în care vrei să muți funcția în afara JSX-ului ca să cureți codul, te lovești de eroarea de implicit any pe parametrul e.
Soluția nu este să îi dai tipul any. Trebuie să folosești tipul corect pus la dispoziție de React, adică React.ChangeEvent<HTMLInputElement>. Sună destul de lung și greu de reținut, dar după ce scrii asta de câteva ori, îți intră în reflex.
5. Object is possibly 'null' la useRef
Vrei să dai focus pe un input folosind un ref. Scrii inputRef.current.focus() și te trezești cu o eroare roșie. TS te avertizează că current poate fi null. Și are dreptate, pentru că la primul render, elementul din DOM nu este încă montat.
Cea mai simplă rezolvare este utilizarea operatorului optional chaining: inputRef.current?.focus(). Acesta verifică dacă elementul există înainte de a apela metoda și te scapă de erori neplăcute în producție.
Strict mode din TypeScript te obligă să fii un programator mai disciplinat, chiar dacă la început pare că te lupți mai mult cu tipurile decât cu logica aplicației. Voi ce erori de TS ați urât cel mai mult când ați început migrarea primului proiect?