type Theme = {
colors: Record<string, string>;
padding: number;
};
// satisfies validează tipul, dar păstrează cheia exactă 'red'
const theme = {
colors: { red: "#ff0000", blue: "#0000ff" },
padding: 16
} satisfies Theme;
// Funcționează perfect pentru că TS știe exact că există 'red':
const redColor = theme.colors.red.toUpperCase();Salutare tuturor. Văd des pe proiectele unde fac consultanță o confuzie destul de mare între adnotarea clasică, aserțiunea de tip (as) și operatorul satisfies adus în TS 4.9. Săptămâna trecută, pe un microserviciu de configurări, am eliminat vreo 40 de aserțiuni inutile și am prevenit două bug-uri care urmau să ajungă în producție.
Hai să le luăm bătrânește, pe cazuri concrete, ca să nu mai tragem la sorți când scriem cod.
1. Adnotarea explicită: Contractul rigid
Când scrii const config: Config = { ... }, îi spui compilatorului: „Vreau ca acest obiect să respecte exact interfața Config”.
E excelentă când vrei să fii avertizat pe loc dacă lipsește ceva. Dar are o mare problemă: lărgește tipurile (type widening). Dacă ai un obiect cu chei dinamice sau culori specifice, TS va uita valorile literale și le va transforma în string. Am pățit asta la un set de rute unde aveam nevoie de căile exacte pentru autocomplete, dar adnotarea explicită le-a redus la un simplu string generic.
2. Operatorul as: Minciuna acceptată
Aserțiunea (as) este modul tău de a-i spune compilatorului: „Taci, știu eu mai bine”.
Uneori e utilă, de exemplu când faci mock-uri în teste sau când lucrezi cu API-uri legacy unde tipurile de pe backend sunt parțiale. Dar în codul de producție, as e o bombă cu ceas. Am dat de un bug în producție unde un data as User a ascuns un câmp lipsă. Codul a compilat perfect, dar a crăpat la runtime când am încercat să citesc user.profile.avatar dintr-un obiect gol. Folosește-l doar dacă chiar nu ai altă variantă.
3. Operatorul satisfies: Cel mai bun compromis
Introdus în TypeScript 4.9, satisfies verifică dacă un obiect respectă o interfață, dar păstrează tipul specific al valorilor introduse.
Este ideal pentru configurări. Dacă ai o paletă de culori și vrei să te asiguri că ai doar culori valide (hex/rgb), dar totuși vrei ca TS să știe exact că theme.colors.primary este "#007bff" (nu doar un string), satisfies este soluția.
4. Ghid decizional în 4 cazuri rapide
Iată cum decid eu pe proiecte ce și când folosesc:
- Cazul A: Configurații de UI sau teme. Folosește
const theme = { ... } as const satisfies Theme. Primești și validare de tip, și imutabilitate la nivel de compilator, și autocomplete perfect. - Cazul B: Răspunsuri de la API sau DTO-uri. Folosește adnotarea explicită (
const payload: UserDTO = ...). Vrei să fii sigur că dacă backend-ul schimbă schema, codul tău nu mai compilează. - Cazul C: Date primite din exterior. Nu folosi niciuna. Folosește o librărie de validare la runtime (precum Zod) pentru a valida schema, apoi lasă TS să deducă tipul.
- Cazul D: Teste unitare. Aici poți folosi
asca să creezi obiecte parțiale fără să fii obligat să adaugi toate proprietățile unui model uriaș.
Trade-off-ul e sincer: satisfies adaugă un pic de complexitate vizuală și necesită o versiune mai nouă de TS, dar elimină complet nevoia de a face type casting periculos.
Voi ce folosiți cel mai des pentru configurări în proiectele voastre? Încă mai aveți fișiere pline de as any?