type Colors = "red" | "blue" | "green";
type Theme = Record<Colors, string | [number, number, number]>;
// Cazul 1: Adnotare explicită - pierdem tipul specific al valorii 'red'
const themeWithAnnotation: Theme = {
red: "#ff0000",
blue: [0, 0, 255],
green: "#00ff00"
};
// EROARE: TS nu știe sigur dacă red e string sau array:
// themeWithAnnotation.red.toUpperCase();
// Cazul 2: satisfies - verifică tipul dar reține că 'red' este string
const themeWithSatisfies = {
red: "#ff0000",
blue: [0, 0, 255],
green: "#00ff00"
} satisfies Theme;
// Funcționează perfect!
themeWithSatisfies.red.toUpperCase();La un proiect mărișor, pe la vreo 15.000 de linii de cod, am făcut marea greșeală să folosesc as (type assertion) ca să scap rapid de erorile de compilare dintr-un config de rute. Ghici ce? Am trimis în producție un typo stupid pe care TypeScript l-a înghițit fără să crâcnească din cauza lui as. De atunci, am reguli stricte în echipă pentru când folosim adnotări clasice, as sau noul operator satisfies.
Hai să le luăm pe rând, ca să nu mai faci aceleași greșeli pe care le-am plătit eu cu ore de debug în weekend.
1. Configurații flexibile unde vrei inferență exactă (Folosește satisfies)
Asta e probabil cea mai faină chestie introdusă în TS 4.9. Vrei să te asiguri că un obiect respectă o anumită structură (o interfață), dar în același timp vrei ca TypeScript să rețină tipurile exacte, literale, ale proprietăților.
Dacă folosești o adnotare explicită (const config: Config = ...), TS va "uita" valorile literale și va folosi tipul mai larg din interfață. Cu satisfies, verifici structura, dar păstrezi precizia maximă pentru autocomplete și type safety ulterior.
2. Definirea de modele stricte de domeniu (Folosește adnotări explicite)
Dacă scrii entități din baza de date, modele de API sau DTO-uri, nu vrei flexibilitate. Vrei contracte stricte. Aici, adnotarea explicită (de genul const user: User = { ... }) este sfântă.
De ce? Pentru că vrei ca compilatorul să urle imediat dacă ai uitat un câmp obligatoriu sau dacă ai adăugat ceva ce nu are ce căuta acolo. Trade-off-ul e că pierzi inferența specifică a valorilor (de exemplu, un string devine doar string, nu valoarea sa literală), dar câștigi consistență.
3. Date externe fără tipuri sigure (Folosește type assertions "as")
Să fim sinceri: as este o minciună convenabilă. Îi spui compilatorului "taci, că știu eu mai bine". Singurul caz unde mai accept as în codebase-urile noastre este atunci când consumăm API-uri legacy sau parsăm JSON-uri unde structura e garantată de un validator extern (cum ar fi Zod), dar tipul returnat în JS e any sau unknown.
Dar atenție mare: dacă folosești as doar ca să scapi de erori la scrierea codului nou, practic anulezi tot sensul utilizării TypeScript.
4. Date imutabile și configurări "Readonly" (as const + satisfies)
Am avut un caz cu o hartă de coduri de eroare și mesaje traduse. Voiam ca toate cheile să fie readonly, dar să mă asigur că respectă o structură de bază. Combinația dintre as const și satisfies e genială aici.
as const face toate proprietățile readonly și le transformă în tipuri literale, iar satisfies verifică dacă structura finală se potrivește cu tipul general de dicționar.
Concluzie și un trade-off sincer
Niciun instrument nu e perfect. satisfies îți oferă cel mai bun mix între flexibilitate și siguranță, dar adaugă puțină complexitate vizuală în cod. Adnotările explicite rămân baza pentru arhitecturi curate, în timp ce as ar trebui limitat la granițele aplicației.
Voi ce reguli aveți în echipă? Mai folosiți as în codul de zi cu zi sau l-ați trimis la pensie?