type Colors = "primary" | "secondary";
type Theme = Record<Colors, string | { rgb: [number, number, number] }>;
// EXPLICIT ANNOTATION (Loses specific type info):
const badTheme: Theme = {
primary: "#ff0000",
secondary: { rgb: [0, 0, 0] }
};
// badTheme.primary.toUpperCase(); // Error! TS thinks primary can be an object
// SATISFIES (Validates, but keeps the exact literal types):
const goodTheme = {
primary: "#ff0000",
secondary: { rgb: [0, 0, 0] }
} satisfies Theme;
goodTheme.primary.toUpperCase(); // Works perfectly! TS knows it's a string.Salutare! Vreau să vorbim un pic despre o dilemă de care mă lovesc des la code reviews, mai ales de când a apărut TS 4.9. Văd mulți colegi care încă folosesc as ca pe un baros sau, dimpotrivă, scriu tipuri explicite peste tot și pierd beneficiile inferenței de tip.
Am avut anul trecut un proiect măricel, un dashboard cu vreo 120 de rute și configurări dinamice pentru grafice. Inițial, toate config-urile erau tipate explicit cu : Record<string, ChartConfig>. Chestia asta ne-a costat vreo două zile de debugging când am vrut să accesăm proprietăți specifice, iar TS ne dădea erori sau ne forța la type guards inutile. Atunci am făcut refactoring și am trecut totul pe satisfies. Am redus erorile de tipare la build-time cu aproape 30%.
Hai să le luăm pe rând, prin 4 cazuri concrete pe care le întâlnești zilnic în cod.
Cazul 1: Când vrei validare, dar vrei să păstrezi tipul exact (The satisfies sweet spot)
Imaginează-ți că ai un obiect de configurări pentru teme (culori, fonturi). Dacă folosești adnotare explicită : Record<string, string>, TS va uita că ai o cheie specifică numită primary. Pentru compiler, orice string e acum o cheie validă.
Dacă folosești satisfies Record<string, string>, TS verifică dacă obiectul tău respectă acea structură, dar păstrează tipul exact al obiectului tău. Știe exact că theme.primary există și e un string, nu îți dă erori când încerci să folosești metode specifice string-urilor.
Cazul 2: Când vrei să minți compilerul cu bună știință (as)
Operatorul as (type assertion) nu este o validare. Este o minciună pe care o spui compilerului: "Crede-mă pe cuvânt, știu eu ce fac".
Singurul loc unde accept as la review este atunci când interacționez cu API-uri externe unde tipurile sunt generate prost, sau la teste rapide. În rest, dacă codul tău are nevoie de as ca să compileze, probabil ai o problemă de design. Trade-off-ul e masiv: dacă API-ul își schimbă structura, TS nu te va avertiza și vei afla doar când crapă aplicația în producție.
Cazul 3: Contractele stricte de API și interfețele publice
Dacă scrii o librărie sau definești structura pe care o returnează o funcție publică, folosește adnotări explicite (const user: User = ...). Aici nu vrei inferență "inteligentă". Vrei ca, dacă adaugi un câmp nou în interfață, compilerul să urle imediat în fișierul unde definești obiectul, nu trei fișiere mai încolo unde este consumat.
Cazul 4: Combinația letală as const + satisfies
Uneori ai configurări read-only pe care vrei să le folosești ca tipuri de uniune mai târziu. De exemplu, o listă de roluri de utilizatori sau rute din aplicație. Folosești as const ca să le faci readonly și literal, dar vrei să te asiguri că respectă o anumită structură. Aici le pui pe amândouă. Obții imutabilitate completă la nivel de tip și validare strictă în același timp.
Care e compromisul real?
satisfies e genial, dar aduce un cost: codul devine mai greu de citit pentru juniori. Am observat că programatorii la început de drum se blochează când văd const config = { ... } satisfies Config. Trebuie să le explici diferența subtilă dintre "upcasting" și "type checking".
Voi ce folosiți cel mai des pentru configurări? Ați reușit să eliminați complet as din codebase-urile voastre?