Сужение по typeof и по истинности

У значения типа string | number нет ни toUpperCase, ни toFixed. Разрешено только то, что есть у обоих вариантов одновременно, — и это разумно: компилятор ведь не знает, что именно придёт в вызове.

function describe(value: string | number): string {
  return value.toUpperCase();
}
console.log(describe("рико"));

Диагностика приходит матрёшкой, как в статье про чтение ошибок: сначала общий вердикт про string | number, следом причина — toUpperCase нет у number. У строки-то метод есть, но этого мало: подойти должны все варианты сразу.

Дальше начинается самое интересное. Добавим проверку — и внутри ветки тип станет другим.

function describe(value: string | number): string {
  if (typeof value === "string") {
    return value.toUpperCase(); // здесь value — уже просто string
  }
  // сюда проверка строку не пустила, значит остался number
  return value.toFixed(2);
}
console.log(describe("рико"));
console.log(describe(3.14159));

Ни одной диагностики. Внутри ветки value — это string, после неё — number, хотя параметр объявлен один раз и одним типом. Компилятор прошёл по коду тем же путём, каким пойдёт исполнение: попасть на шестую строку можно, только не выполнив условие, — а значит, строка отпадает. Этот разбор называют анализом потока управления, а его результат — сужением типа.

Отсюда главный вывод статьи: тип переменной — не один на всю функцию, а свой в каждой точке кода. Объявление задаёт лишь верхнюю границу, дальше её сужают проверки. Наведите в редакторе курсор на value внутри ветки и сразу за ней — подсказка покажет для одного имени два разных типа.

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

function probe(value: string | number): void {
  if (typeof value === "string") {
    // намеренно врём с типом: текст диагностики назовёт то, что мы выясняем
    const check: null = value;
    console.log(check);
  }
}
probe("рико");

В части I typeof был способом спросить у значения, что оно такое. В TypeScript у него появилась вторая работа: компилятор читает такое сравнение и подстраивает тип. Сам список ответов не изменился.

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

function twice(value: unknown): void {
  if (typeof value === "number") {
    console.log(value * 2); // здесь unknown уже сузился до number
    return;
  }
  console.log("не число: " + typeof value);
}
twice(21);
twice("21");
twice([1, 2]);

unknown из главы про базовые типы наружу ничего не выпускал, пока ему не докажешь, что там лежит. Вот и доказательство. Заметьте, что проверка нужна не компилятору: без неё умножение массива на два дало бы тихий NaN и в обычном JavaScript.

Сужает не любая проверка, а сравнение typeof со строковым литералом. Если такого варианта в объединении нет, ветка просто становится мёртвой — и компилятор об этом молчит.

function warn(value: string | number): void {
  if (typeof value === "boolean") {
    console.log("логическое значение: " + value);
  }
  console.log("проверка закончена");
}
warn("рико");
warn(42);

Внутри условия value имеет тип never: не осталось ни одного варианта, который сюда прошёл бы. Синтаксически всё законно, поэтому претензий нет, — а код внутри не выполнится никогда. Тому, как из этого never сделать пользу, отведена отдельная статья главы.

const wanted = "string";
function pick(value: string | number): void {
  if (typeof value === wanted) {
    console.log(value.toUpperCase());
  }
}
pick("рико");

О том, что typeof null возвращает "object", вы читали в части I: ошибка первой реализации языка, которую уже не исправить без поломки половины интернета. В типизированном коде она перестаёт быть забавным фактом.

function printTags(tags: string[] | null): void {
  if (typeof tags === "object") {
    console.log(tags.length);
  }
}
printTags(["новости", "спорт"]);
printTags(null);

Компилятор эту ловушку знает: TS18047, «Возможно, tags имеет значение null». Проверка честно пропустила оба варианта — и массив, и null одинаково отвечают "object", — поэтому внутри ветки остался ровно тот же тип string[] | null, что был снаружи. Сузить не удалось ничего.

Дальше — показательный случай: диагностику проигнорировали, код всё равно запустился, первый вызов напечатал двойку, а второй упал настоящим TypeError. Компилятор указывал ровно на ту строку, где рвануло.

Лечится это не хитрой проверкой, а обычным сравнением — тем самым, о котором шла речь в соседней статье про strictNullChecks.

function printTags(tags: string[] | null): void {
  if (tags !== null) {
    console.log(tags.length);
    return;
  }
  console.log("тегов нет");
}
printTags(["новости", "спорт"]);
printTags(null);

tags !== null отсекает ровно то, что мешало, и в ветке остаётся string[]. А различать между собой объекты, массивы и экземпляры классов typeof не умеет вовсе — для них есть in, instanceof и Array.isArray, им посвящена следующая статья.

На объект typeof отвечает "object" всегда: и на массив, и на дату, и на null. Полезной информации в этом ответе почти нет.

Второй способ сузить тип обходится вообще без слов: значение просто ставят в условие. Список ложных значений компилятор знает почти тот же, что и вы, — false, 0, 0n, "", null, undefined, NaN, — и вычитает из типа всё, что могло бы оказаться ложным. Восьмого значения из списка языка — -0 — здесь нет: для компилятора это тот же тип, что 0.

function greet(name: string | undefined): string {
  if (name) {
    return "Привет, " + name.toUpperCase(); // undefined сюда не проходит
  }
  return "Привет, гость";
}
console.log(greet("рико"));
console.log(greet(undefined));
console.log(greet(""));

В истинной ветке name — это string, и метод строки берётся без придирок. А вот что осталось в ложной, угадывают неверно почти все.

Строка в ложную ветку возвращается: пустая строка ложна, но она полноправная string. С массивом иначе — пустой массив истинен, поэтому в else остаётся один null. А последняя строка таблицы объясняет, почему проверка на истинность иногда не даёт ничего: и строка, и число бывают ложными, вычитать нечего.

Компилятор тут точнее человеческой интуиции. И следующий пример — про то, чего он поймать не может в принципе.

function report(count: number | undefined): void {
  if (count) {
    console.log("получено " + count.toFixed(0));
  } else {
    console.log("данных нет");
  }
}
report(12);
report(0);
report(undefined);

Ни одной диагностики — с точки зрения типов всё безупречно: toFixed вызван у числа. Врёт логика. Ноль — это полноценные данные, а if (count) отправил его туда же, куда и отсутствующее значение. Такую ошибку компилятор не найдёт никогда: вы попросили отсечь всё ложное, он отсёк.

function report(count: number | undefined): void {
  if (typeof count === "number") {
    console.log("получено " + count.toFixed(0));
    return;
  }
  console.log("данных нет");
}
report(12);
report(0);
report(undefined);

typeof count === "number" спрашивает ровно то, что нужно, и ноль остаётся числом. Сравнение count !== undefined сделало бы то же самое — выбор между ними дело вкуса, важно лишь не спрашивать «истинно ли», когда на самом деле интересует «есть ли».

Истинность годится, когда ноль и пустая строка означают ровно то же, что отсутствие значения. Во всех остальных случаях спрашивайте прямо.

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

let value: string | number = "рико";
if (typeof value === "string") {
  value = value.length;
  console.log(value.toUpperCase());
}

Проверка в заголовке говорит «строка», но к моменту вызова там уже число — и компилятор это отследил: в диагностике назван number, а не string | number. На исполнении получаем TypeError, дословно подтверждающий сказанное.

Куда неожиданнее ведёт себя отложенный код. Сужение доезжает до колбэка — если переменной больше нигде не присваивают.

function schedule(name: string | undefined): void {
  if (name) {
    setTimeout(() => {
      console.log(name.toUpperCase());
    }, 0);
  }
}
schedule("рико");

А теперь допишем в самый конец функции одну строку. Она выполнится задолго до колбэка — таймер ждёт, пока освободится стек, это разбиралось в статье «Event loop: как браузер успевает всё».

function schedule(name: string | undefined): void {
  if (name) {
    setTimeout(() => {
      console.log(name.toUpperCase());
    }, 0);
  }
  name = undefined;
}
schedule("рико");

TS18048 на четвёртой строке, хотя изменилась восьмая. Рассуждение честное: колбэк выполнится когда-то потом, а к тому времени в изменяемой переменной может лежать любое значение из объявленного типа. Пока присваиваний нет — сужение остаётся в силе; появилось хоть одно, хоть в конце функции, — и внутри отложенного кода тип снова полный. Здесь компилятор не придирается: код действительно падает.

Сужение отменяет присваивание где угодно в функции, а не только до колбэка. Компилятор смотрит на весь срок жизни переменной.

function schedule(name: string | undefined): void {
  if (name) {
    const current = name;
    setTimeout(() => {
      console.log(current.toUpperCase());
    }, 0);
  }
  name = undefined;
}
schedule("рико");