import React, { useState, useRef } from 'react';
interface User {
id: number;
name: string;
}
interface ProfileCardProps {
title: string;
children: React.ReactNode; // Rezolvă eroarea 1 (children implicitly any)
}
export const ProfileCard = ({ title, children }: ProfileCardProps) => {
// Rezolvă eroarea 4 (useState generic în loc de never[])
const [users, setUsers] = useState<User[]>([]);
const inputRef = useRef<HTMLInputElement>(null);
// Rezolvă eroarea 2 (typing corect pentru evenimente)
const handleInputChange = (e: React.ChangeEvent<HTMLInputElement>) => {
console.log(e.target.value);
};
const focusInput = () => {
// Rezolvă eroarea 3 (optional chaining pentru obiecte care pot fi null)
inputRef.current?.focus();
};
return (
<div>
<h2>{title}</h2>
{children}
<input ref={inputRef} onChange={handleInputChange} />
<button onClick={focusInput}>Focus</button>
</div>
);
};Dacă tocmai ai trecut de la JavaScript chior la React cu TypeScript strict, probabil îți vine să arunci laptopul pe geam din cauza erorilor de compilare. Am trecut și eu prin asta la primul proiect serios în TS, prin 2018, când totul părea o luptă continuă cu compilatorul. Partea bună e că după ce treci de primele hopuri, n-o să mai vrei să scrii JS simplu în viața ta.
În modul strict: true (pe care îl recomand cu căldură în orice tsconfig.json), TypeScript nu te lasă să trișezi. Hai să vedem cele mai comune 5 erori de care te lovești în prima săptămână și cum le rezolvi curat, fără să pui any peste tot.
1. Binding element 'children' implicitly has an 'any' type
Scrii un wrapper simplu pentru un layout, destructurezi props-urile și te trezești cu eroare de compilare pe children. În TS strict, compilatorul are nevoie să știe exact ce tip de date primește componenta ta.
Poți folosi tipul utilitar React.ReactNode. Personal, prefer să definesc o interfață explicită pentru props, în loc să folosesc tipul generic React.FC.
Trade-off: React.FC adăuga automat children în versiunile mai vechi de React, dar venea la pachet cu alte limitări la generice. Să scrii props-urile explicit e un pic mai mult boilerplate, dar codul devine mult mai lizibil pentru oricine îl citește după tine.
2. Parameter 'e' implicitly has an 'any' type la inputuri
Dacă scrii un handler inline, de genul onChange={(e) => setValue(e.target.value)}, TS își dă seama singur de tipul argumentului. Însă, dacă muți funcția în afara JSX-ului ca să păstrezi codul curat, compilatorul începe să urle.
Soluția este să folosești tipul corect de eveniment din React. Pentru un input clasic de text, tipul este React.ChangeEvent<HTMLInputElement>. La început o să ți se pară un abuz de taste, dar te asigur că te va ajuta enorm când ai formulare complexe și vrei să fii sigur de ce proprietăți are obiectul de eveniment.
3. Object is possibly 'null' la useRef
Când vrei să pui focusul pe un input folosind un ref, scrii de obicei useRef(null). Când încerci să apelezi inputRef.current.focus(), primești eroarea asta.
E logic: la prima randare, DOM-ul nu e încă încărcat, deci ref-ul chiar este null. Trebuie să folosești optional chaining (inputRef.current?.focus()) sau o verificare clasică cu if. Da, scrii o linie de cod în plus, dar elimini complet riscul de a crăpa aplicația în runtime din cauza unui element lipsă.
4. useState cu array-uri goale care devin 'never[]'
Inițializezi un state pentru o listă de utilizatori: const [users, setUsers] = useState([]). Când încerci să adaugi un utilizator nou în listă cu setUsers([...users, newUser]), TS îți dă o eroare bizară despre tipul never.
Pentru că ai inițializat useState cu un array gol, TS a presupus că acel array va rămâne gol pentru totdeauna (tipul never[]). Soluția este să folosești un tip generic când definești state-ul: useState<User[]>([]). În felul ăsta, compilatorul știe exact la ce să se aștepte pe viitor.
5. Capcana lui 'any' la apelurile API
La un proiect cu vreo 12k useri activi, un coleg a pus tipul any pe răspunsul de la un API de facturare. Backend-ul a schimbat un câmp din snake_case în camelCase la un update, iar aplicația a crăpat direct în producție pentru că TS nu a văzut nicio problemă la compilare.
Folosește interfețe clare pentru tot ce vine din API. Dacă chiar nu știi structura datelor sau aceasta e dinamică, folosește unknown în loc de any și fă validare de tip (type guarding) înainte să folosești datele.
Tranziția la TypeScript strict adaugă un overhead de timp la început — estimez cam 20% timp în plus la development în prima lună. Însă, pe termen lung, te scutește de ore întregi de debugging pe bug-uri stupide de tipar.
Care a fost eroarea de TypeScript care v-a mâncat cele mai multe ore la primul proiect?