null, undefined и strictNullChecks

В части I обе величины прошли в списке восьми типов, и разница между ними была скорее договорённостью команды, чем правилом языка. TypeScript превращает договорённость в правило: null и undefined — два разных типа, и в объединении они стоят порознь.

type User = { name: string; boss: string | null };
const rico: User = { name: "Рико", boss: null };
console.log(rico.boss);
const team: User[] = [rico];
console.log(team.find((u) => u.name === "Аня"));
console.log(null === undefined);
console.log(null == undefined);

Разделение держится не на синтаксисе, а на смысле. null кто-то написал: поле есть, значения в нём осознанно нет. undefined обычно никто не писал — оно возникает там, где значения не оставили.

type Settings = { theme?: string };
const settings: Settings = {};
console.log(settings.theme);
function save(): void {
  console.log("сохранили");
}
console.log(save());
function greet(name?: string): void {
  console.log("Привет, " + name);
}
greet();

Три поставщика undefined из примера — отсутствующее свойство, функция без return и непереданный аргумент — дают почти весь undefined, который встречается в жизни. Четвёртый, самый коварный, — выход за границу массива; до него дойдём в конце статьи.

Уклад, который стоит держать во всём проекте: null — «пусто, и так задумано»; undefined — «значения тут никто не оставлял».

До этого флага (и сегодня в любом проекте, где он выключен) null и undefined считались допустимыми значениями любого типа. Написано string — а лежать там могло что угодно из трёх.

let title: string = "Кофе";
title = null;
console.log(title.toUpperCase());

Диагностика ровно одна, и стоит она на второй строке: Тип "null" не может быть назначен для типа "string". Без флага её бы не было — а TypeError на третьей строке остался бы точно таким же. Разница только в том, кто первым увидит проблему: вы за десять секунд или пользователь через неделю.

Хотите допустить пустоту — скажите это в типе. Компилятор возражать не станет, но теперь он знает про неё и не даст забыть.

function shout(title: string | null): void {
  console.log(title.toUpperCase());
}
shout("кофе");
shout(null);

Обратите внимание на счёт: вызова два, падение одно, а диагностика — одна и не про вызовы вовсе. Возможно, "title" имеет значение null сказано про тип, а не про сегодняшний запуск. Компилятор не гадает, что придёт в функцию, — он читает объединение string | null и видит вариант, для которого toUpperCase не существует.

Сообщений на самом деле два семейства. Первое появляется на присваивании и на аргументе: вы кладёте пустоту туда, где её не ждут. Второе — на чтении: вы обращаетесь к значению, в типе которого пустота есть.

const users = ["Рико", "Аня", "Лена"];
const found = users.find((name) => name.length > 10);
console.log(found.toUpperCase());

Метод find возвращает string | undefined — и это не придирка типов, а его настоящее поведение из части I: не нашёл, вернул undefined. Компилятор цитирует имя переменной, чтобы в длинной строке было видно, о ком речь: Возможно, "found" имеет значение undefined.

Последняя строка таблицы объясняет, почему в одних сообщениях есть имя, а в других — безличное «объект». Цитировать компилятору нечего, если читают прямо у результата вызова.

type User = { name: string };
function findUser(id: number): User | null {
  return id === 1 ? { name: "Рико" } : null;
}
console.log(findUser(2).name);
function maybeUser(id: number): User | null | undefined {
  return id === 1 ? { name: "Рико" } : null;
}
console.log(maybeUser(2).name);

Смысл у всех шести кодов один: в типе есть вариант, для которого точка после значения не имеет смысла. Разница только в том, сколько вариантов пустоты в объединении и нашлось ли выражению имя.

Диагностика стоит там, где значение читают, а не там, где оно появилось. Тип приехал раньше — иногда из чужого файла.

Первый способ — обычная проверка, та самая, которую вы написали бы и без всякого TypeScript. Компилятор читает поток выполнения и внутри ветки считает тип уже суженным.

type Product = { id: number; title: string };
const products: Product[] = [{ id: 1, title: "Кофе" }];
function titleOf(id: number): string {
  const found = products.find((p) => p.id === id);
  // ранний возврат: ниже этой строки found — уже точно Product
  if (found === undefined) {
    return "товар не найден";
  }
  return found.title;
}
console.log(titleOf(1), titleOf(2));

Ноль диагностик и ноль падений. Заметьте, что ни одной строки «ради компилятора» здесь нет: без этой проверки код упал бы на втором вызове и в обычном JavaScript. Сам механизм сужения устроен интереснее, чем кажется, — ему посвящена следующая статья.

Второй способ — ?. и ?? из части I. В типах они работают ровно так же, как в браузере, только теперь их видит ещё и компилятор.

type User = { name: string; city?: string };
const user: User = { name: "Рико" };
console.log(user.city?.toUpperCase());
console.log(user.city ?? "город не указан");
const len: number = user.city?.length ?? 0;
console.log(len);

Важная деталь строки с len: ?. не устраняет пустоту, а переносит её на результат. Тип выражения user.city?.length — number | undefined, поэтому в переменную number он сам по себе не ляжет; закрывает вопрос уже ??.

Третий способ — одна проверка на обе пустоты сразу. Это единственное место, где нестрогое сравнение из статьи про сравнения и их ловушки не считается дурным тоном: == null истинно ровно для null и undefined и ни для чего больше.

function trimmed(text: string | null | undefined): string {
  // == null ловит обе пустоты разом, поэтому здесь оно уместно
  if (text == null) {
    return "пусто";
  }
  return text.trim();
}
console.log(trimmed("  Рико  "));
console.log(trimmed(null));
console.log(trimmed(undefined));

type Row = { title: string; discount: number | null };
const row: Row = { title: "Кофе", discount: 0 };
console.log(row.discount || 15);
console.log(row.discount ?? 15);

type User = { name: string | null };
const user: User = { name: "Рико" };
if (user.name !== null) {
  setTimeout(() => {
    console.log(user.name.toUpperCase());
  }, 0);
}

type User = { name: string | null };
const user: User = { name: "Рико" };
if (user.name !== null) {
  // константа фиксирует проверенное значение
  const name = user.name;
  setTimeout(() => {
    console.log(name.toUpperCase());
  }, 0);
}

Есть способ убрать любую из этих диагностик за один символ. Восклицательный знак после значения означает: «я знаю, что здесь не пусто».

const scores = new Map<string, number>();
scores.set("Рико", 10);
const value = scores.get("Аня");
console.log(value + 1);
console.log(value!.toFixed(1));

Сравните две последние строки. На четвёртой компилятор предупредил — и получился безобидный NaN. На пятой он промолчал — и вышло падение. Разница между строками ровно в одном символе, и этот символ не сделал код безопаснее: он снял с компилятора обязанность проверять.

! ничего не проверяет и ничего не меняет в скомпилированном коде — из результата он просто исчезает. Это утверждение о типе, родной брат as из статьи про unknown, только короче.

type Product = { id: number; title: string };
const products: Product[] = [{ id: 1, title: "Кофе" }];
function titleOf(id: number): string {
  // ! обещает, что товар найдётся всегда
  return products.find((p) => p.id === id)!.title;
}
console.log(titleOf(1));
console.log(titleOf(2));

Обещание написано в одном месте, а нарушает его чужой вызов из другого. Пока в каталоге есть товар с нужным номером, всё работает; ошибку принесёт первый запрос с чужим номером — и виноватой будет выглядеть строка внутри titleOf, до которой никто не дотрагивался.

Полностью запрещать ! смысла нет: бывают случаи, где вы действительно знаете больше компилятора. Но каждый такой знак — это заметка «я умнее анализа потока», и её стоит подписывать причиной, как любое неочевидное решение. У typescript-eslint для этого есть отдельное правило, о нём разговор в главе про настройку проекта.

const list: number[] = [1, 2, 3];
const item = list[10];
console.log(item.toFixed(1));