Uniunile Discriminate (cunoscute și ca Tagged Unions sau Algebraic Data Types) reprezintă cel mai important model de design arhitectural din TypeScript. În loc să modelăm o stare printr-un obiect cu zeci de proprietăți opționale (de exemplu { isLoading: boolean, data?: User[], error?: string }, care permite stări imposibile precum isLoading: true și error: "Eroare" simultan), uniunile discriminate fac stările invalide imposibil de reprezentat.
// Definim fiecare stare ca pe un tip de sine stătător cu o proprietate literală comună ('status'):
type StareCerere =
| { status: 'inactiv' }
| { status: 'incarcare' }
| { status: 'succes'; date: string[]; timestamp: number }
| { status: 'eroare'; cod: number; mesaj: string };
function randeazaUi(stare: StareCerere): string {
switch (stare.status) {
case 'inactiv':
return 'Apasă butonul pentru a începe.';
case 'incarcare':
return 'Se încarcă datele...';
case 'succes':
// TypeScript restrânge automat tipul: 'date' este garantat prezent!
return `Date recepționate: ${stare.date.join(', ')}`;
case 'eroare':
// 'cod' și 'mesaj' sunt disponibile doar aici:
return `Eroare ${stare.cod}: ${stare.mesaj}`;
}
}Verificarea Exhaustivă (Exhaustiveness Checking) cu tipul never
Ce se întâmplă dacă peste 6 luni un coleg adaugă o nouă stare în uniune (de exemplu | { status: 'anulat' }), dar uită să actualizeze funcția randeazaUi? Fără o verificare exhaustivă, codul va compila fără eroare, dar la runtime va returna silențios undefined!
Tehnica exhaustivă folosește faptul că tipul never reprezintă o stare imposibilă căreia nu i se poate atribui nicio valoare:
function proceseazaStareExhaustiv(stare: StareCerere) {
switch (stare.status) {
case 'inactiv':
return "Inactiv";
case 'incarcare':
return "Încărcare";
case 'succes':
return "Succes";
case 'eroare':
return "Eroare";
default:
// Dacă toate cazurile au fost tratate, 'stare' are tipul 'never'.
// Dacă un caz a fost omis, atribuirea de mai jos va declanșa o EROARE DE COMPILARE:
const _verificareExhaustiva: never = stare;
throw new Error(`Caz netratat: ${JSON.stringify(_verificareExhaustiva)}`);
}
}Beneficiile Majore ale Tipului never în Arhitectură
- Refactorizare fără frică: Dacă adăugați un nou membru într-o uniune de evenimente sau comenzi, compilatorul
tscvă va indica exact toate locurile din aplicație unde trebuie să implementați logica pentru noul caz. - Zero State Bugs: Elimină complet combinările contradictorii de flag-uri booleene (cum ar fi
isSuccess === true && isError === true).
Întrebări & Exemple de Cod:
Uniuni Discriminate și Verificare Exhaustivă cu Tipul neverAi o nelămurire despre utilizarea comenzii
Uniuni Discriminate și Verificare Exhaustivă cu Tipul neversau ai descoperit un truc / fragment de cod util? Distribuie-l cu ceilalți programatori!Fii primul care pune o întrebare sau distribuie un fragment de cod / prompt!
Nu au fost adăugate încă întrebări sau exemple de cod pentru această pagină. Dacă ai întâlnit o problemă sau ai un snippet util, adaugă-l mai jos pentru a-i ajuta pe ceilalți.