null y undefined en TypeScript: comprobaciones, ?. y ??

Con strictNullChecks activado (forma parte de strict), null y undefined son tipos propios. Un string nunca puede ser null; un valor que puede faltar tiene que decirlo en su tipo, como string | null, y TypeScript te obliga a manejar ese caso antes de usar el valor.

function initials(name: string | null | undefined): string {
  if (name == null) return "?"; // handles both null and undefined
  return name
    .split(" ")
    .map((part) => part[0])
    .join("");
}

console.log(initials("Ada Lovelace")); // AL
console.log(initials(null));           // ?
console.log(initials(undefined));      // ?

Tras la comprobación, el compilador sabe que name es un string, así que se permite .split. El resto de esta página explica las formas de hacer esa comprobación y los operadores que la acortan.

strictNullChecks y los errores «possibly null»

Cuando un tipo incluye null o undefined, TypeScript se niega a usar el valor como si siempre estuviera ahí:

// This does not compile: name may be null
function greet(name: string | null) {
  return "Hello, " + name.toUpperCase();
}

console.log(greet("ada"));

index.ts(3,22): error TS18047: 'name' is possibly 'null'.

La versión con undefined es TS18048, 'x' is possibly 'undefined'. Sin strictNullChecks, null y undefined se permiten en todos los tipos y este código compila, y luego falla en tiempo de ejecución con un TypeError la primera vez que name es null. Ese tipo de bug es la razón principal para mantener strict activado.

De dónde salen estos tipos en el código de todos los días:

Comprobar null y undefined

Cada una de estas comprobaciones estrecha el tipo dentro del bloque. Elige la que corresponda a lo que quieres excluir.

function label(value: string | null | undefined): string {
  if (value === undefined) return "undefined";
  if (value === null) return "null";
  return value.toUpperCase(); // value is string here
}

function orNone(value: string | null | undefined): string {
  if (value == null) return "(none)"; // == null matches null AND undefined
  return `"${value}"`;
}

console.log(label(undefined), label(null), label("ok")); // undefined null OK
console.log(orNone(null), orNone(undefined), orNone("")); // (none) (none) ""

== null es el único sitio donde la igualdad laxa es idiomática: es true exactamente para null y undefined, y para nada más. Una comprobación de veracidad habría tratado el string vacío como si faltara, lo que a menudo es un bug.

Encadenamiento opcional: ?.

a?.b lee b si a no es null ni undefined, y si lo es se detiene y devuelve undefined. El mismo operador funciona con índices, a?.[i], y con llamadas, fn?.().

interface User {
  name: string;
  address?: { city: string; zip?: string };
  tags?: string[];
  onLogin?: () => string;
}

const ada: User = { name: "Ada", address: { city: "London" }, onLogin: () => "welcome" };
const bob: User = { name: "Bob" };

console.log(ada.address?.city);        // London
console.log(bob.address?.city);        // undefined
console.log(ada.address?.zip?.length); // undefined
console.log(bob.tags?.[0]);            // undefined
console.log(ada.onLogin?.());          // welcome
console.log(bob.onLogin?.());          // undefined

El tipo de bob.address?.city es string | undefined: el encadenamiento opcional añade undefined al resultado, así que normalmente se combina con ??. El comportamiento en tiempo de ejecución es JavaScript normal; consulta encadenamiento opcional para los detalles del cortocircuito.

El doble signo de interrogación: ??

a ?? b devuelve a salvo que sea null o undefined, en cuyo caso devuelve b. Sustituye a la antigua expresión a || b, que además descarta 0, "", false y NaN:

function pageSize(input: number | undefined): string {
  const withOr = input || 20;      // 0 is falsy, so it is replaced
  const withNullish = input ?? 20; // only undefined is replaced
  return `${withOr} vs ${withNullish}`;
}

console.log(pageSize(undefined)); // 20 vs 20
console.log(pageSize(0));         // 20 vs 0

const scores = new Map([["Ada", 90]]);
const score: number = scores.get("Linus") ?? 0; // number | undefined becomes number
console.log(score);                             // 0

En cuanto a los tipos, ?? quita null y undefined del lado izquierdo y une el resto con el lado derecho, y por eso scores.get("Linus") ?? 0 se puede asignar a un number.

Asignación nula: ??=

a ??= b asigna b a a solo cuando a es null o undefined. Sus hermanos ||= y &&= asignan cuando el lado izquierdo es falsy o truthy.

interface Options {
  retries?: number;
  label?: string;
}

function withDefaults(opts: Options) {
  opts.retries ??= 3;   // assign only if null or undefined
  opts.label ||= "job"; // assign if falsy, so "" is replaced too
  return opts;
}

console.log(withDefaults({}));                       // { retries: 3, label: 'job' }
console.log(withDefaults({ retries: 0, label: "" })); // { retries: 0, label: 'job' }

retries: 0 sobrevive a ??=, mientras que ||= sustituye el label vacío. Tras opts.retries ??= 3, TypeScript estrecha opts.retries a number en el resto de la función.

Propiedades opcionales frente a | undefined

nickname?: string y nickname: string | undefined se leen igual, pero se diferencian en si la clave tiene que existir:

interface WithOptional { nickname?: string }            // key may be missing
interface WithUndefined { nickname: string | undefined } // key must be present

const a: WithOptional = {};
const b: WithUndefined = { nickname: undefined };

// @ts-expect-error: Property 'nickname' is missing in type '{}' but required in type 'WithUndefined'.
const c: WithUndefined = {};

console.log("nickname" in a, "nickname" in b); // false true
console.log(a.nickname === b.nickname);        // true: both read as undefined

Usa ? cuando quien llama pueda omitir la propiedad, y | undefined cuando quieras que todos la pasen de forma explícita, aunque el valor sea undefined. La opción exactOptionalPropertyTypes (no forma parte de strict) endurece más ?: nickname?: string rechaza entonces { nickname: undefined } y solo acepta una clave ausente o un string. Los parámetros opcionales de las funciones (x?: number) se comportan como las propiedades opcionales: dentro de la función x es number | undefined.

null o undefined: cuál usar

TypeScript no obliga a elegir, pero mezclar los dos en un mismo proyecto significa que cada comprobación tiene que manejar dos casos. Una convención habitual:

• Usa undefined (y propiedades opcionales) para «no asignado» en tus propios tipos. Es lo que JavaScript produce por defecto: propiedades que no existen, argumentos omitidos, find y Map.get sin resultado.
• Acepta null donde te lo da una API: JSON no tiene undefined, y String.prototype.match y muchos métodos del DOM devuelven null.
• Comprueba con == null cuando un valor pueda ser cualquiera de los dos.

La indexación de arrays es el único hueco: users[5] tiene el tipo de los elementos aunque el índice esté fuera de rango. La opción noUncheckedIndexedAccess (no forma parte de strict) añade | undefined a cada acceso por índice para que el compilador también lo detecte.