Point d'exclamation en TypeScript : l'assertion non nulle (!)

Un point d'exclamation après une expression, value!, est l'opérateur d'assertion non nulle. Il retire null et undefined du type, si bien qu'un number | undefined peut être utilisé comme un number. C'est une promesse faite au compilateur, pas une vérification : rien ne se passe à l'exécution.

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

Sans le !, tea.toFixed(2) provoque l'erreur TS18048, 'tea' is possibly 'undefined'. Avec lui, le code compile parce que vous avez dit au compilateur que la clé existe.

Ce que fait x! à l'exécution : rien

Le ! est effacé de la sortie. Le JavaScript compilé pour prices.get("coffee")! est simplement prices.get("coffee"). Si l'assertion est fausse, l'erreur apparaît plus tard, au premier endroit où la valeur manquante est utilisée :

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);
}

Le programme affiche Cannot read properties of undefined (reading 'toFixed'). Le plantage a lieu sur la ligne qui suit le !, et dans du vrai code il peut survenir bien plus loin : le undefined peut être stocké dans un objet et exploser dans un autre fichier. C'est cette distance qui rend ! risqué.

Assignation définie : let x!: T

Le même symbole dans une déclaration a un sens voisin. TypeScript suit si une variable est assignée avant d'être lue, et il ne peut pas suivre une assignation faite dans une autre fonction :

// 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 }; est une assertion d'assignation définie : « elle sera assignée avant toute lecture ». Elle corrige l'erreur, avec le même inconvénient que x! : si init() est un jour sauté, la lecture obtient undefined. Restructurer vaut en général mieux, par exemple const config = init(); avec un init qui renvoie l'objet.

Propriétés de classe : prop!: T

Avec strictPropertyInitialization (qui fait partie de strict), chaque propriété de classe doit être initialisée dans sa déclaration ou dans le constructeur. Sinon, vous obtenez TS2564 : Property 'socket' has no initializer and is not definitely assigned in the constructor. Quand une propriété est définie plus tard par une méthode ou un framework, prop!: T demande au compilateur de l'accepter :

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

Le premier console.log montre la faille : le type dit que socket est toujours là, mais avant open() il vaut undefined. Appeler c.socket.send à ce moment compile et lève une exception. Si la propriété peut réellement manquer, déclarez-la socket?: ... et vérifiez-la, ou créez l'objet dans le constructeur. Le principal cas où prop! est une pratique standard est un framework qui remplit une propriété après la construction : le @ViewChild(...) child!: ChildDirective d'Angular (défini avant l'exécution de ngAfterViewInit), ou les classes d'entités d'un ORM dont la bibliothèque remplit les colonnes en chargeant une ligne (la documentation de MikroORM écrit @Property() title!: string).

Des alternatives plus sûres

La plupart des ! peuvent être remplacés par quelque chose que le compilateur vérifie, ou par une vérification qui échoue bruyamment au bon endroit :

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
}

Les deux helpers affinent le type comme le fait !, mais une hypothèse fausse produit missing HOST sur-le-champ au lieu d'une TypeError ailleurs. assertDefined est une fonction d'assertion (asserts value is ...) : après l'appel, le compilateur traite host comme un string. D'autres motifs dans type guards.

Les autres points d'exclamation

! n'a pas le même sens selon sa position :

Seuls les deux premiers sont effacés à la compilation. !value et !!value s'exécutent et renvoient un booléen.