Как обработать такое исключение с помощью TS?

Question

[Gary_Ihar]

type Item = {
  title: string
}
const arr : Item[] = []
const a = arr[0].title.length //error , но TS молчит

Comments

[VitalyChaikin]

а в чём ошибка ?! в том что нулевой элемент не существует ?

[Gary_Ihar]

VitalyChaikin, да

Answer 1

[Станислав Макаров]

const arr1 : [Item, ...Item[]] = [{ title: 'a' }] // OK
const arr2 : [Item, ...Item[]] = [] // Не скомпилируется

Playground

Используя такой tuple-тип вместо обычного массива, вы можете ПОТРЕБОВАТЬ наличия некоторого количества элементов в начале массива.

Comments

[Alexandroppolus]

А толку-то?

arr1.pop();
const a = arr1[0].title.length //error , но TS молчит

[Станислав Макаров]

Alexandroppolus
1) TypeScript сейчас не выполняет проверку типов для целочисленных индексов. Проверка по длине работает для tuple-ов, например если у вас есть переменная типа [Item] | [Item, Item], то при проверке на length TypeScript сузит вам тип до [Item] или [Item, Item]
2) То что вы хотите - смена типа переменной в результате смены состояния объекта - в TS нет и врядли будет в ближайшее время. Проверять такое очень сложно на этапе компиляции. Сейчас в TS есть control flow typing в виде сужения типа переменной в ветвях условий при использовании встроенных или пользовательских type guards.

[Gary_Ihar]

Станислав Макаров, спасибо за информацию!

[Alexandroppolus]

Станислав Макаров, это всё понятно, я лишь заметил, что в общем виде это проверить нельзя. Частные случаи - да, но не более.

В отличии от массивов, объекты, к примеру, вполне тайпчекаются

type Item = {
  title: string
}
const o: Item = {
  title: '4545'
}

delete o.title; // TS не молчит

Answer 2

[Дмитрий Беляев]

Если TS выше 4.1 то добавьте в tsconfig.json в compilerOptions:
"noUncheckedIndexedAccess": true
TS будет ругаться на непроверенный доступ по индексу

Comments

[Gary_Ihar]

Сделали на проекте так, но появились другие косяки) тс теперь ругается в очень очевидных местах

[Дмитрий Беляев]

Gary_Ihar, это да, ввод более строгих правил на существующем проекте всегда приводит к новым репортам, зато защищает от возможных ошибок.
Один раз выделить время и поправить, по другому никак.
Где-то стоит действительно проверок добавить - ибо так как раз и выявляются скрытые баги.
Ну а где точно уверены, что проверка не нужна, это можно закрыть через ! (non null assertion) оператор

Так же советую еще это правило в eslint добавить