import React, { useState, useRef } from 'react';
interface User {
id: number;
name: string;
}
export const UserForm = () => {
// Soluție Eroare 2: Specificăm tipul generic pentru array
const [users, setUsers] = useState<User[]>([]);
// Soluție Eroare 4: Tipăm useRef-ul cu elementul HTML corespunzător
const inputRef = useRef<HTMLInputElement>(null);
// Soluție Eroare 3: Folosim tipul de eveniment specific din React
const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
console.log(e.target.value);
};
const handleFocus = () => {
// Optional chaining previne eroarea de 'possibly null'
inputRef.current?.focus();
};
return (
<div>
<input ref={inputRef} onChange={handleChange} />
<button onClick={handleFocus}>Focus</button>
</div>
);
};Dacă tocmai ai trecut de la JavaScript la React cu strict: true în tsconfig, probabil îți vine să arunci laptopul pe geam. Roșul ăla din VS Code pe care-l vezi la fiecare pas nu e acolo ca să te pedepsească, ci ca să te scape de bug-uri penibile în producție. Am pățit și eu asta acum vreo 6 ani, când am migrat un proiect de 14k linii de cod; prima săptămână a fost pură frustrare până m-am prins cum gândește compilatorul.
TypeScript strict te forțează să fii explicit. Hai să luăm la rând cele mai frecvente cinci erori pe care le vei întâlni și să vedem cum le repari fără să pui any peste tot.
1. Binding element implicitly has an 'any' type
În JavaScript chior, scriai destul de relaxat componentele destructurând props-urile direct în semnătura funcției:
const Button = ({ label, onClick }) => { ... }
În modul strict, TypeScript urlă imediat. El nu știe ce este label sau onClick. Soluția cinstită este să definești un interface clar pentru proprietățile componentei tale. Astfel, oricine folosește componenta va fi obligat să trimită datele corecte.
2. Statul inițializat cu array gol devine 'never[]'
Scrii codul ăsta clasic: const [users, setUsers] = useState([]). Totul pare în regulă până când încerci să faci setUsers([{ name: 'Adi' }]). TypeScript îți aruncă o eroare bizară: Argument of type '...' is not assignable to parameter of type 'never'.
De ce se întâmplă asta? Pentru că ai inițializat useState cu un array gol, iar TS a dedus că acel array va rămâne gol pentru totdeauna (tipul never[]). Soluția este să folosești un tip generic ca să-i spui compilatorului ce fel de date va conține acel array pe parcursul ciclului de viață al componentei.
3. Property 'value' does not exist on type 'EventTarget'
Vrei să citești valoarea dintr-un input la un eveniment de onChange:
const handleChange = (e) => { setValue(e.target.value) }
Aici primești erori pe bandă rulantă. În primul rând, e are implicit tipul any. În al doilea rând, chiar dacă îi pui tipul generic de eveniment, e.target s-ar putea să nu aibă proprietatea value în viziunea TypeScript. Trebuie să folosești tipurile specifice pe care React le pune la dispoziție pentru evenimentele din DOM.
4. Object is possibly 'null' la useRef
Când vrei să pui un ref pe un input ca să-i dai focus programatic, scrii probabil const inputRef = useRef(null). Când încerci să apelezi inputRef.current.focus(), TypeScript te blochează: Object is possibly 'null'.
Aici compilatorul are perfectă dreptate. La primul render, elementul din DOM încă nu există, deci ref-ul este într-adevăr null. Pentru a rezolva problema, trebuie să tastezi corect ref-ul și să folosești optional chaining (?.) când accesezi proprietatea current.
5. Element implicitly has an 'any' type because expression of type 'string' can't be used to index
Ai un obiect simplu de configurare, de exemplu culorile pentru diferite statusuri, și încerci să-l accesezi dinamic folosind un string primit ca prop:
const colors = { active: 'green', inactive: 'gray' };
const myColor = colors[status];
TS se panichează deoarece status este un simplu string, iar el nu poate garanta că acel string se va potrivi exact cu cheile 'active' sau 'inactive'. Va trebui să îi explici compilatorului că stringul tău este de fapt una dintre cheile specifice ale acelui obiect.
Trade-off-ul sincer
Să fim realiști: TypeScript strict îți va scădea viteza de dezvoltare cu vreo 20-30% în primele săptămâni. Te vei lupta cu tipurile mai mult decât vei scrie logică de business. Totuși, când ajungi să faci refactoring pe o componentă critică folosită în 10 locuri diferite, TypeScript își scoate banii instant.
Cum a fost prima voastră săptămână cu strict: true? V-a venit să reveniți la JS sau a fost dragoste la prima compilare?