Punto esclamativo in TypeScript: la non-null assertion (!)

Un punto esclamativo dopo un'espressione, value!, è l'operatore di non-null assertion. Toglie null e undefined dal tipo, così un number | undefined si può usare come un number. È una promessa fatta al compilatore, non un controllo: a runtime non succede niente.

const prices = new Map<string, number>([
  ["tea", 2.5],
  ["coffee", 3.2],
]);

const tea = prices.get("tea");         // number | undefined
const coffee = prices.get("coffee")!;  // number

console.log(coffee.toFixed(2)); // 3.20
console.log(tea!.toFixed(2));   // 2.50: ! works on any expression

Senza il !, tea.toFixed(2) è l'errore TS18048, 'tea' is possibly 'undefined'. Con il !, il codice compila perché hai detto al compilatore che la chiave esiste.

Cosa fa x! a runtime: niente

Il ! viene cancellato dall'output. Il JavaScript compilato per prices.get("coffee")! è semplicemente prices.get("coffee"). Se l'asserzione è sbagliata, l'errore compare più avanti, nel primo punto in cui si usa il valore mancante:

const prices = new Map<string, number>([["tea", 2.5]]);

try {
  const juice = prices.get("juice")!; // compiles: the ! silences the check
  console.log(juice.toFixed(2));      // TypeError at runtime
} catch (e) {
  console.log((e as Error).message);
}

Il programma stampa Cannot read properties of undefined (reading 'toFixed'). Il crash avviene nella riga dopo il !, e nel codice reale può essere molto più lontano: l'undefined può finire salvato in un oggetto ed esplodere in un altro file. È quella distanza a rendere rischioso il !.

Definite assignment: let x!: T

Lo stesso simbolo in una dichiarazione ha un significato affine. TypeScript tiene traccia di se una variabile viene assegnata prima di essere letta, e non riesce a seguire un'assegnazione fatta dentro un'altra funzione:

// This does not compile: TypeScript cannot see the assignment inside init()
let config: { port: number };

function init() {
  config = { port: 8080 };
}

init();
console.log(config.port);

index.ts(9,13): error TS2454: Variable 'config' is used before being assigned.

let config!: { port: number }; è una definite assignment assertion: "verrà assegnata prima di qualsiasi lettura". Risolve l'errore, con lo stesso rischio di x!: se init() viene saltata, la lettura ottiene undefined. Di solito è meglio ristrutturare, per esempio const config = init(); con init che restituisce l'oggetto.

Proprietà di classe: prop!: T

Con strictPropertyInitialization (parte di strict), ogni proprietà di classe deve essere inizializzata nella sua dichiarazione o nel costruttore. Altrimenti ottieni TS2564: Property 'socket' has no initializer and is not definitely assigned in the constructor. Quando una proprietà viene impostata più tardi da un metodo o da un framework, prop!: T dice al compilatore di accettarla:

class Connection {
  url: string;
  socket!: { send(msg: string): string }; // set in open(), not in the constructor

  constructor(url: string) {
    this.url = url;
  }

  open() {
    this.socket = { send: (msg) => `sent "${msg}" to ${this.url}` };
  }
}

const c = new Connection("ws://example.com");
console.log(c.socket);            // undefined: declared but not set yet
c.open();
console.log(c.socket.send("hi")); // sent "hi" to ws://example.com

Il primo console.log mostra il buco: il tipo dice che socket c'è sempre, ma prima di open() è undefined. Chiamare c.socket.send in quel momento compila e lancia un errore. Se la proprietà può davvero mancare, dichiarala socket?: ... e controllala, oppure crea l'oggetto nel costruttore. Il caso principale in cui prop! è la pratica standard è un framework che riempie una proprietà dopo la costruzione: il @ViewChild(...) child!: ChildDirective di Angular (impostato prima che venga eseguito ngAfterViewInit), o le classi entità degli ORM, le cui colonne vengono riempite dalla libreria quando carica una riga (la documentazione di MikroORM scrive @Property() title!: string).

Alternative più sicure

La maggior parte dei ! si può sostituire con qualcosa che il compilatore controlla, o con un controllo che fallisce in modo evidente nel punto giusto:

function must<T>(value: T | null | undefined, what: string): T {
  if (value == null) throw new Error(`missing ${what}`);
  return value;
}

function assertDefined<T>(value: T, what: string): asserts value is NonNullable<T> {
  if (value == null) throw new Error(`missing ${what}`);
}

const env = new Map([["PORT", "8080"]]);

const port = must(env.get("PORT"), "PORT"); // string
console.log(Number(port) + 1);              // 8081

const host = env.get("HOST");
try {
  assertDefined(host, "HOST");
  console.log(host.toUpperCase()); // host is string after the assertion
} catch (e) {
  console.log((e as Error).message); // missing HOST
}

Entrambi gli helper restringono il tipo come fa !, ma un'ipotesi sbagliata produce missing HOST sul posto invece di un TypeError da qualche altra parte. assertDefined è una assertion function (asserts value is ...): dopo la chiamata, il compilatore tratta host come una string. Altri schemi nei type guards.

Gli altri punti esclamativi

! significa cose diverse a seconda di dove si trova:

Solo i primi due vengono cancellati in fase di compilazione. !value e !!value vengono eseguiti a runtime e restituiscono un booleano.