Signo de exclamación en TypeScript: la aserción non-null (!)

Un signo de exclamación después de una expresión, value!, es el operador de aserción non-null. Quita null y undefined del tipo, así que un number | undefined se puede usar como un number. Es una promesa al compilador, no una comprobación: en tiempo de ejecución no pasa nada.

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

Sin el !, tea.toFixed(2) es el error TS18048, 'tea' is possibly 'undefined'. Con él, el código compila porque le dijiste al compilador que la clave existe.

Qué hace x! en tiempo de ejecución: nada

El ! se borra de la salida. El JavaScript compilado de prices.get("coffee")! es simplemente prices.get("coffee"). Si la aserción es errónea, el error aparece más tarde, en el primer sitio donde se usa el valor que falta:

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

El programa imprime Cannot read properties of undefined (reading 'toFixed'). El fallo ocurre en la línea que sigue al !, y en código real puede estar mucho más lejos: el undefined puede guardarse en un objeto y estallar en otro archivo. Esa distancia es la razón de que ! sea arriesgado.

Asignación definitiva: let x!: T

El mismo símbolo en una declaración significa algo relacionado. TypeScript registra si una variable se asigna antes de leerse, y no puede seguir una asignación hecha dentro de otra función:

// 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 }; es una aserción de asignación definitiva: «esto se asignará antes de cualquier lectura». Arregla el error, con la misma pega que x!: si alguna vez se salta init(), la lectura obtiene undefined. Suele ser mejor reestructurar, por ejemplo const config = init(); con init devolviendo el objeto.

Propiedades de clase: prop!: T

Con strictPropertyInitialization (parte de strict), cada propiedad de clase debe inicializarse en su declaración o en el constructor. Si no, obtienes TS2564: Property 'socket' has no initializer and is not definitely assigned in the constructor. Cuando un método o un framework asigna la propiedad más tarde, prop!: T le dice al compilador que la acepte:

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

El primer console.log muestra el hueco: el tipo dice que socket siempre está ahí, pero antes de open() es undefined. Llamar a c.socket.send en ese momento compila y lanza un error. Si la propiedad de verdad puede faltar, declárala socket?: ... y compruébala, o crea el objeto en el constructor. El sitio principal donde prop! es práctica estándar es un framework que rellena una propiedad después de la construcción: el @ViewChild(...) child!: ChildDirective de Angular (asignado antes de que se ejecute ngAfterViewInit), o las clases de entidad de un ORM cuyas columnas rellena la librería al cargar una fila (la documentación de MikroORM escribe @Property() title!: string).

Alternativas más seguras

La mayoría de los ! se pueden sustituir por algo que el compilador comprueba, o por una comprobación que falla de forma clara en el sitio correcto:

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
}

Las dos funciones auxiliares estrechan el tipo igual que !, pero una suposición errónea produce missing HOST en el acto en lugar de un TypeError en otro sitio. assertDefined es una función de aserción (asserts value is ...): después de la llamada, el compilador trata host como un string. Hay más patrones en type guards.

Los otros signos de exclamación

! significa cosas distintas según dónde esté:

Solo los dos primeros se borran al compilar. !value y !!value se ejecutan en tiempo de ejecución y devuelven un booleano.