type Color = string | { r: number; g: number; b: number };
type Theme = Record<string, Color>;
// Cu adnotare clasică: pierdem tipul specific (TS crede că e doar "Color")
const themeWithAnnotation: Theme = {
primary: "#ff0000",
secondary: { r: 0, g: 255, b: 0 }
};
// EROARE: Property 'toUpperCase' does not exist on type 'Color'
themeWithAnnotation.primary.toUpperCase();
// Cu satisfies: validăm structura, dar păstrăm tipul specific
const themeWithSatisfies = {
primary: "#ff0000",
secondary: { r: 0, g: 255, b: 0 }
} satisfies Theme;
// Funcționează perfect! TS știe că primary e string
themeWithSatisfies.primary.toUpperCase();Salutare! Văd des confuzia asta pe proiecte, inclusiv la oameni cu destulă experiență în spate. Ne-am obișnuit toți să trântim un : după variabilă sau un as când compilatorul începe să plângă. Am pățit-o acum un an la un refactoring pe un modul de configurare cu vreo 80 de rute dinamice: tipizasem totul cu Record<string, Route>, dar IDE-ul pierdea complet autocomplete-ul pe cheile specifice. Atunci m-am prins de ce satisfies (introdus în TS 4.9) e o mică minune, dar și unde dă rateuri.
Hai să le luăm la bani mărunți prin 4 cazuri concrete pe care le întâlnești zilnic în producție.
Cazul 1: Configurații flexibile, dar cu autocomplete precis (satisfies)
Ai un obiect de configurare unde unele valori pot fi string-uri sau array-uri de string-uri. Dacă folosești adnotarea clasică (ex: const config: Record<string, string | string[]>), TypeScript va uita ce tip exact ai pus la fiecare cheie. Când vrei să apelezi .join() pe o proprietate care știi sigur că e array, compilatorul va urla că s-ar putea să fie string.
Aici strălucește satisfies. Validează că obiectul respectă structura generală, dar păstrează tipurile specifice ale valorilor pe care le-ai scris efectiv. Primești eroare dacă pui o cheie greșită, dar păstrezi tipul cel mai îngust posibil pentru fiecare proprietate.
Cazul 2: Contracte stricte în API-uri (Adnotarea clasică)
Dacă scrii un controller sau un serviciu care trebuie să returneze exact o anumită interfață (de exemplu, un UserResponse), folosește adnotarea clasică (const res: UserResponse = ...).
De ce? Pentru că vrei ca TypeScript să te oblige să trimiți toate câmpurile obligatorii, chiar dacă tu ai uitat de ele. satisfies te lasă uneori să scapi cu un obiect parțial dacă tipul de bază are proprietăți opționale, pe când adnotarea clasică îți dă instant palme peste degete dacă lipsește ceva ce backend-ul așteaptă neapărat.
Cazul 3: Date externe sau mock-uri în teste (as)
Operatorul as (type assertion) este, în 90% din cazuri, o minciună gogonată pe care o spui compilatorului. Îi zici: „crede-mă pe cuvânt, știu eu mai bine ce fac”.
Singurul loc unde îl tolerez (și unde chiar e util) este în teste sau când mapăm payload-uri venite din API-uri legacy unde n-avem scheme de validare runtime. Dacă ai nevoie de un obiect mock pentru teste și interfața are 50 de câmpuri, dar tu testezi doar o funcție de trimis mail care are nevoie doar de email și name, folosești as User ca să nu scrii un boilerplate gigantic. În producție însă, as ascunde bug-uri sub preș.
Cazul 4: Definirea de teme sau design tokens
Am avut cazul unei teme de UI cu culori primare și secundare care puteau fi fie hex (#ff0000), fie obiecte cu nuanțe ({ light, dark }). Dacă foloseam as, pierdeam validarea la scriere. Dacă foloseam : (adnotare), compilatorul nu mai știa dacă theme.colors.primary e string sau obiect când o apelam în componente. satisfies a rezolvat asta elegant, economisindu-ne timp prețios de debugging pe UI.
Trade-off-ul sincer
satisfies e genial pentru narrowing, dar are o mare problemă: tooltip-urile din IDE devin absolut gigantice și greu de citit pentru că TypeScript încearcă să afișeze tipul inferat extrem de specific în loc de numele interfeței generale. Pe proiecte mari, asta poate îngreuna înțelegerea codului la code review.
Voi ce folosiți cel mai des pentru obiectele de configurare? Mai are as vreun loc în codul vostru de producție?