Che cosa sono i Literal Types in TypeScript e a cosa servono? Come possono essere utilizzati per implementare restrizioni severe sui valori delle variabili e quali tranelli ci sono nel loro utilizzo?

Risposta

I Literal Types consentono di limitare i possibili valori di una variabile a determinate costanti rigide, e non a un semplice tipo generale (ad esempio, non semplicemente un numero, ma il numero 5 o la stringa "yes").

Questo è utile per creare API con parametri fissi, stati, ecc.

type Direction = 'left' | 'right' | 'up' | 'down';

function move(dir: Direction) {
  // ...
}

move('left'); // OK
move('top');  // Errore di compilazione!

Funzionano anche con numeri, boolean e persino strutture intere (tuple literal type):

type WeekDay = 1 | 2 | 3 | 4 | 5 | 6 | 7;
const day: WeekDay = 6; // OK

Limitazioni e sfumature:

• Non è possibile convertire implicitamente valori ai tipi letterali (ad esempio, non è possibile assegnare a una variabile di tipo 'left' | 'right' una stringa da input dell'utente senza controllo).
• Quando si lavora con costanti e variabili let, è importante ricordare il tipo di inferenza:

const d = 'left'; // ha tipo 'left' (Literal)
let e = 'left';   // ha tipo string (normale)

Domanda trabocchetto

Domanda: Che tipo avrà la variabile se la definisco come const x = "yes"; — e posso poi assegnarle un altro valore stringa?

Risposta:

• Se dichiaro const x = "yes"; — x avrà il tipo "yes" (literal type), e non si potrà assegnare alcun altro valore oltre a 'yes' (e non può essere cambiato in quanto const).
• Se dichiaro let x = "yes";, allora x sarà tipizzata come string, e sarà possibile assegnare qualsiasi stringa.

const x = 'yes'; // x: 'yes'
let y = 'yes';   // y: string

Esempi di errori reali a causa della mancanza di conoscenza delle sottigliezze del tema.

---

Storia

Nel progetto per gli stati delle attività è stato utilizzato un enum, ma lo sviluppatore lo ha sostituito con una stringa. Di conseguenza, l'API ha iniziato ad accettare qualsiasi stringa come stato, portando a molti bug durante lo sviluppo del prodotto in produzione, poiché il controllo è andato perso.

---

Storia

Lo sviluppatore ha cercato di utilizzare i tipi letterali per la convalida dei dati, ma ha assegnato i parametri dal campo del modulo direttamente — TS ha consentito di farlo, poiché il tipo del campo input era string e non literal (ad esempio, "ok" | "fail"), poiché i valori di input non erano stati verificati. Di conseguenza, durante il runtime apparivano valori non appartenenti all'insieme di quelli consentiti.

---

Storia

Durante la scrittura dei test per una funzione che accettava valori letterali, un test generato automaticamente ha accidentalmente fornito un parametro string inaspettato, i test non sono passati. Successivamente si è scoperto che la tipizzazione era stata indebolita a causa della disattenzione all'inferenza dei tipi durante la dichiarazione let, e il compilatore non l'ha rilevato.