interface User {
id: string;
name: string;
email: string;
role: 'admin' | 'user';
passwordHash: string;
}
// Creăm un tip pentru update parțial (PATCH)
type UserUpdate = Partial<User>;
// Creăm un tip pentru UI-ul de listă, fără date sensibile
type UserPreview = Pick<User, 'id' | 'name' | 'role'>;
// Scoatem parola pentru obiectul de sesiune
type SessionUser = Omit<User, 'passwordHash'>;
function getUser() {
return { id: '1', name: 'Eduard', active: true };
}
// Extragem tipul returnat de o funcție
type UserFromFn = ReturnType<typeof getUser>;Hai să fim serioși, mulți scriem TypeScript ca pe un fel de 'JavaScript cu extra pași' și ajungem să duplicăm interfețele de ne ia gaia. Am avut un proiect anul trecut unde aveam un model de User cu vreo 40 de câmpuri și făceam manual interfețe noi pentru fiecare formă de editare sau listare. O prostie monumentală care ne-a mâncat vreo 3 zile de refactoring inutil când s-a schimbat un singur tip de dată în baza de date.
Utility types nu sunt acolo doar ca să dea bine la interviurile de seniori, ci ca să nu mai muncești tu ca robotul. Te ajută să păstrezi o singură sursă de adevăr (Single Source of Truth) pentru datele tale.
Partial și Required: Jocurile cu formulare
Cel mai des m-am lovit de Partial când am avut de implementat sisteme de autosave sau update-uri parțiale (PATCH). Ai un obiect mare de setări, dar userul modifică doar un toggle. Nu vrei să trimiți tot obiectul la API și nici nu vrei să scrii manual o interfață nouă unde toate câmpurile au semnul întrebării.
Totuși, există un trade-off sincer aici: Partial e periculos dacă uiți că totul devine undefined. Am pățit-o de câteva ori să dau de erori în runtime pentru că logica mea internă se baza pe un câmp care, deși în interfața originală era obligatoriu, în Partial dispăruse. Required e opusul lui și e util mai ales după ce treci printr-un proces de mapare sau filtrare și vrei să fii sigur că obiectul rezultat e complet.
Pick și Omit: Chirurgie pe interfețe
Aici e "carnea" adevărată. De câte ori n-ai avut nevoie de un UserPreview care are doar id, name și avatar? În loc să faci o interfață nouă, dai un Pick<User, 'id' | 'name' | 'avatar'>. E mult mai curat și, dacă cineva schimbă tipul lui id din number în string la nivel global, se propagă automat peste tot.
Omit e la fel de util când vrei să scoți chestii sensibile. La un proiect cu 8k useri activi, aveam un obiect de sesiune care includea tot userul din DB, inclusiv hash-ul de parolă și niște token-uri interne. Am folosit Omit ca să curățăm obiectul înainte să-l trimitem către frontend. Am economisit timp și am redus riscul de securitate fără să rescriem tot sistemul de autentificare.
ReturnType: Când n-ai control pe cod
Asta e preferata mea când lucrez cu librării externe sau cu factory functions complexe. Uneori, o funcție dintr-un SDK returnează un obiect anonim gigant. Decât să încerci să-i ghicești structura sau să o scrii manual (și să crape la următorul update de librărie), folosești ReturnType<typeof funcțiaMea>.
Am salvat cam 30% din timpul de scriere a tipurilor la o integrare cu un SDK de plăți care avea zero documentație pe tipuri, dar funcțiile lor erau, surprinzător, tipizate corect intern. TypeScript a extras singur structura răspunsului pentru mine.
Concluzia mea sinceră
Utility types sunt bune până când transformi codul într-o ciorbă de tipuri imbricate. Dacă ajungi să scrii ceva de genul Pick<Partial<Omit<T, 'a'>>, 'b'>, oprește-te. E momentul să declari o interfață nouă, clară. TypeScript e despre claritate și DX (developer experience), nu despre cine scrie cel mai complex oneliner pe care nici autorul nu-l mai înțelege peste două săptămâni.
Voi ce folosiți mai des pentru a evita duplicarea interfețelor din API?