Параметр strictNullChecks определяет, будет ли TypeScript считать null и undefined отдельными типами или нет. Если параметр выключен (по умолчанию до версии 2.0), переменные любого типа могут принимать значения null и undefined без ошибок компиляции. Если включён (strictNullChecks: true), эти значения считаются несовместимыми с другими типами за исключением случаев, когда это явно указано.
Пример:
// strictNullChecks: false let name: string = null; // OK // strictNullChecks: true let title: string = null; // Ошибка! let title2: string | null = null; // OK, явное объединение типов
Включение строгой проверки помогает избежать ошибок на ранних этапах разработки, когда функции/методы не рассчитывают на возможность получения null или undefined.
Можно ли присвоить переменной типа
numberзначениеundefinedпри включённом strictNullChecks?
Ответ: Нет, если включён strictNullChecks, то переменной типа number нельзя присвоить undefined — только если явно объявить тип как number | undefined.
Пример:
let count: number = undefined; // TS Error при strictNullChecks: true let count2: number | undefined = undefined; // OK
История
На одном крупном node.js-проекте разработчики отключили строгую проверку null/undefined для «облегчения миграции». В результате через год после запуска одна из функций API вернула undefined вместо числового значения. Клиентский код не был к этому готов, из-за чего приложение на стороне пользователя фатально падало при простом вычислении response.count + 1.
История
В ecommerce-проекте коллекция товаров пришла с сервера как null, а не []. UI-компонент делал map по этим товарам, вызывая у каждого свойство — выпадала ошибка рендеринга. Включение strictNullChecks сразу высветило почти 40 аналогичных мест.
История
В крупной библиотеке со временем число «разрешённых» значений для некоторых пропсов component API стало string | null | undefined. Это привело к массе необработанных ситуаций. После включения strictNullChecks удалось отловить неочевидные баги с падениями интерфейса при специфических конфигурациях.