Wykrzyknik w TypeScript: non-null assertion (!)

Wykrzyknik po wyrażeniu, value!, to operator non-null assertion. Usuwa null i undefined z typu, więc number | undefined można użyć jako number. To obietnica dana kompilatorowi, a nie sprawdzenie: w czasie działania nic się nie dzieje.

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

Bez ! wywołanie tea.toFixed(2) to błąd TS18048, 'tea' is possibly 'undefined'. Z nim kod się kompiluje, bo zapewniasz kompilator, że klucz istnieje.

Co x! robi w czasie działania: nic

! jest usuwany z wyniku kompilacji. Skompilowany JavaScript dla prices.get("coffee")! to po prostu prices.get("coffee"). Jeśli asercja jest błędna, błąd pojawia się później, w pierwszym miejscu, gdzie brakująca wartość zostaje użyta:

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

Program wypisuje Cannot read properties of undefined (reading 'toFixed'). Awaria następuje w linii po !, a w prawdziwym kodzie może być znacznie dalej: undefined może trafić do obiektu i wybuchnąć w zupełnie innym pliku. Ta odległość sprawia, że ! jest ryzykowny.

Definite assignment: let x!: T

Ten sam symbol w deklaracji oznacza coś pokrewnego. TypeScript śledzi, czy zmienna została przypisana przed odczytem, ale nie potrafi prześledzić przypisania wykonanego w innej funkcji:

// 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 }; to definite assignment assertion: "zostanie przypisana przed każdym odczytem". Usuwa błąd, z tym samym haczykiem co x!: jeśli init() kiedyś zostanie pominięte, odczyt dostanie undefined. Zwykle lepiej zmienić strukturę kodu, na przykład const config = init();, gdzie init zwraca obiekt.

Właściwości klas: prop!: T

Przy strictPropertyInitialization (część strict) każda właściwość klasy musi być zainicjalizowana w deklaracji lub w konstruktorze. W przeciwnym razie dostajesz TS2564: Property 'socket' has no initializer and is not definitely assigned in the constructor. Gdy właściwość ustawia później metoda lub framework, prop!: T każe kompilatorowi ją zaakceptować:

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

Pierwsze console.log pokazuje lukę: typ mówi, że socket zawsze istnieje, ale przed open() jest undefined. Wywołanie c.socket.send w tym momencie się kompiluje i rzuca wyjątek. Jeśli właściwości naprawdę może brakować, zadeklaruj ją jako socket?: ... i sprawdzaj, albo twórz obiekt w konstruktorze. Główne miejsce, gdzie prop! to standardowa praktyka, to framework wypełniający właściwość po utworzeniu obiektu: @ViewChild(...) child!: ChildDirective w Angularze (ustawiane przed uruchomieniem ngAfterViewInit) albo klasy encji ORM, których kolumny biblioteka wypełnia przy wczytywaniu wiersza (dokumentacja MikroORM pisze @Property() title!: string).

Bezpieczniejsze alternatywy

Większość ! da się zastąpić czymś, co kompilator sprawdza, albo sprawdzeniem, które głośno zawodzi we właściwym miejscu:

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
}

Obie funkcje pomocnicze zawężają typ tak jak !, ale błędne założenie od razu daje missing HOST zamiast TypeError gdzieś indziej. assertDefined to funkcja asercji (asserts value is ...): po wywołaniu kompilator traktuje host jako string. Więcej wzorców w type guards.

Inne wykrzykniki

! znaczy różne rzeczy w zależności od tego, gdzie stoi:

Tylko dwa pierwsze są usuwane podczas kompilacji. !value i !!value działają w czasie wykonania i zwracają boolean.