import React, { useRef, useState } from 'react';
interface ButtonProps {
label: string;
onClick: () => void;
children?: React.ReactNode; // Obligatoriu în React 18+
}
export const CustomButton = ({ label, onClick, children }: ButtonProps) => {
const inputRef = useRef<HTMLInputElement>(null);
const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
console.log(e.target.value);
};
return (
<div onClick={() => inputRef.current?.focus()}>
<label>{label}</label>
<input ref={inputRef} onChange={handleChange} />
{children}
</div>
);
};Am văzut zeci de juniori care, după prima zi de React cu TypeScript, vor să arunce laptopul pe geam. Configurația de strict: true în tsconfig.json e ca un polițist care te oprește pentru un bec ars în timp ce tu încerci să ajungi la spital. Dar, după 10 ani de scris cod, îți zic sincer: polițistul ăla are dreptate. Majoritatea erorilor de runtime pe care le aveam în 2015 au dispărut pur și simplu pentru că TS m-a obligat să fiu atent la detalii.
Nu e vorba de „overengineering”, ci de siguranță. La un proiect recent cu peste 120 de componente, TS ne-a salvat de cel puțin 5 incidente în producție doar prin simplul fapt că ne-a blocat build-ul când un coleg a uitat să updateze un tip de date după un refactoring masiv. Hai să vedem unde se rupe filmul cel mai des.
1. Coșmarul evenimentelor din formulare
Cea mai clasică eroare: încerci să citești e.target.value și primești eroarea că e are tipul any sau că target nu există pe tipul respectiv. Tendința e să pui any și să mergi mai departe. Nu face asta.
Soluția corectă este să folosești tipurile oferite de React, cum ar fi React.ChangeEvent<HTMLInputElement>. E un trade-off: scrii un pic mai mult, dar ai autocomplete pe tot ce înseamnă proprietăți de input. Am economisit cam 30% din timpul de scriere a formularelor doar pentru că nu a mai trebuit să dau console.log la fiecare eveniment să văd unde e stocat textul.
2. useRef și obsesia pentru null
Când declari un ref pentru un element din DOM, mulți scriu useRef<HTMLDivElement>(). TS o să țipe imediat când încerci să folosești myRef.current.focus(). De ce? Pentru că la prima randare, elementul nu există încă.
Trebuie să îl inițializezi cu null și să pui mereu un „optional chaining” sau un if-statement. Pare redundant să verifici mereu dacă un div există, dar crede-mă, am văzut destule crash-uri de tipul „cannot read property of null” în Sentry pentru că cineva a uitat că un element poate fi ascuns condiționat.
3. Unde a dispărut props.children?
Dacă ai învățat React acum 2-3 ani, știai că React.FC includea automat children. Din versiunea 18, echipa React a scos asta. Acum, dacă vrei o componentă wrapper, trebuie să definești explicit children: React.ReactNode în interfața de props. E o schimbare care a frustrat multă lume, inclusiv pe mine la început, dar face codul mult mai predictibil. Știi exact dacă o componentă e gândită să primească alte elemente în interior sau nu.
4. Eroarea de tip „Binding element has implicitly an any type”
Asta se întâmplă când faci destructuring la props fără să le dai un tip. TS nu are de unde să știe ce e user sau id dacă nu îi spui.
interface UserProfileProps {
name: string;
age: number;
isAdmin?: boolean;
}
Folosirea unei interfețe clare te forțează să te gândești la arhitectura datelor înainte să scrii logica. La un proiect cu 8k useri activi, am descoperit că aveam date incomplete venite din baza de date doar pentru că am definit un prop ca fiind obligatoriu în TS și am văzut că în anumite scenarii lipsea.
5. Fetch și iluzia siguranței
TS nu te protejează de ce vine din rețea la runtime. Dacă faci fetch la un JSON, tipul returnat e any. Mulți fac greșeala să creadă că dacă au pus as MyType, datele chiar vor arăta așa.
Trade-off-ul aici e între viteză și siguranță: poți să „minți” compiler-ul cu un type assertion, sau poți să folosești o librărie ca Zod pentru validare. Eu recomand ca măcar pentru obiectele critice să ai o minimă verificare. Nu e nimic mai frustrant decât să ai un cod care „trece” de TS, dar crapă în browser pentru că backend-ul a trimis null în loc de array.
TypeScript strict e greu în primele două săptămâni, apoi devine a doua natură. Voi ce eroare de tip „Type is not assignable” ați înjurat cel mai tare azi?