null i undefined w TypeScript: sprawdzanie oraz operatory ?. i ??

Przy włączonym strictNullChecks (to część strict) null i undefined mają własne typy. string nigdy nie może być null; wartość, której może brakować, musi to zaznaczyć w swoim typie, na przykład string | null, a TypeScript każe ci obsłużyć ten przypadek przed użyciem wartości.

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));      // ?

Po sprawdzeniu kompilator wie, że name to string, więc .split jest dozwolone. Reszta strony omawia sposoby takiego sprawdzania i operatory, które je skracają.

strictNullChecks i błędy "possibly null"

Gdy typ zawiera null lub undefined, TypeScript nie pozwala używać wartości tak, jakby zawsze istniała:

// 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'.

Wersja dla undefined to TS18048, 'x' is possibly 'undefined'. Bez strictNullChecks null i undefined są dozwolone w każdym typie i ten kod się kompiluje, a potem wywala się w czasie działania z TypeError, gdy tylko name okaże się null. Ta klasa błędów to główny powód, by trzymać strict włączone.

Skąd te typy biorą się w codziennym kodzie:

Sprawdzanie null i undefined

Każde z poniższych sprawdzeń zawęża typ wewnątrz bloku. Wybierz to, które pasuje do tego, co chcesz wykluczyć.

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 to jedyne miejsce, gdzie luźna równość jest idiomatyczna: jest prawdziwe dokładnie dla null i undefined, dla niczego więcej. Sprawdzenie prawdziwości potraktowałoby pusty string jako brak wartości, co często jest błędem.

Optional chaining: ?.

a?.b odczytuje b, jeśli a nie jest null ani undefined, a w przeciwnym razie zatrzymuje się i zwraca undefined. Ten sam operator działa dla indeksów, a?.[i], i dla wywołań, 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

Typ bob.address?.city to string | undefined: optional chaining dodaje undefined do wyniku, więc zwykle łączy się go z ??. Zachowanie w czasie działania to zwykły JavaScript; szczegóły skracania obliczeń znajdziesz w optional chaining.

Podwójny znak zapytania: ??

a ?? b zwraca a, chyba że to null lub undefined, wtedy zwraca b. Zastępuje starszy idiom a || b, który odrzuca też 0, "", false i 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

Na poziomie typów ?? usuwa null i undefined z lewej strony i łączy resztę w unię z prawą stroną, dlatego scores.get("Linus") ?? 0 można przypisać do number.

Nullish assignment: ??=

a ??= b przypisuje b do a tylko wtedy, gdy a to null lub undefined. Jego rodzeństwo, ||= i &&=, przypisuje, gdy lewa strona jest fałszywa lub prawdziwa.

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 przetrwa ??=, a pusty label zostaje zastąpiony przez ||=. Po opts.retries ??= 3 TypeScript zawęża opts.retries do number do końca funkcji.

Właściwości opcjonalne a | undefined

nickname?: string i nickname: string | undefined przy odczycie wyglądają tak samo, ale różnią się tym, czy klucz musi istnieć:

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

Użyj ?, gdy wywołujący mogą pominąć właściwość, a | undefined, gdy chcesz, żeby każdy wywołujący przekazał ją jawnie, nawet jeśli wartość to undefined. Opcja exactOptionalPropertyTypes (nie jest częścią strict) jeszcze bardziej zaostrza ?: wtedy nickname?: string odrzuca { nickname: undefined } i przyjmuje tylko brak klucza albo string. Opcjonalne parametry funkcji (x?: number) zachowują się jak właściwości opcjonalne: wewnątrz funkcji x ma typ number | undefined.

null czy undefined: czego używać

TypeScript nie wymusza wyboru, ale mieszanie obu w jednym projekcie oznacza, że każde sprawdzenie musi obsłużyć dwa przypadki. Popularna konwencja:

• Używaj undefined (i właściwości opcjonalnych) dla "nieustawione" we własnych typach. To właśnie domyślnie produkuje JavaScript: brakujące właściwości, pominięte argumenty, nieudane find i Map.get.
• Przyjmuj null tam, gdzie daje ci go API: JSON nie ma undefined, a String.prototype.match i wiele metod DOM zwraca null.
• Sprawdzaj przez == null, gdy wartość może być jednym albo drugim.

Jedyną luką jest indeksowanie tablic: users[5] ma typ elementu, nawet gdy indeks wykracza poza zakres. Opcja noUncheckedIndexedAccess (nie jest częścią strict) dodaje | undefined do każdego dostępu przez indeks, więc kompilator wyłapuje także to.