filter((itm): itm is number => itm !== undefined) Можно вот так в старом тайпскрипте. Инлайновый typeguard Генерик версия для особо упоротых: itm is NonNullable
костыли... системой типов это решаться должно. undefined должен быть потомком всех типов, тогда и union специалььный для него не нужен. Попробуйте Elm - надеюсь, там-то хоть по-нормальному сделано.
Автор всё доходчиво объяснил и показал! Раньше действительно была проблема, что TS не отслеживал что мы фильтруем и тип, который он вычислил вначале использовался везде. Это заставляло вставлять дополнительные проверки, чтобы можно было обратиться к объекту. Теперь с этим проблем не должно быть.
@@VitalyVasilega это должна быть проблема не языка, а статических линтеров Как компилятор угадает рантаймовый фильтр? В сигнатурах типов указываются все ограничения, остальное - линтинг
@@kirillgimranov4943 боже мой, ts это не язык, а надстройка и статический анализатор. Как угадать? Угадывать не нужно, всё видно по AST. Почему-то Elm может, ReScript (OCaml) может, а в ts только сейчас осилили.
@@kirillgimranov4943 C такой логикой type narrowing существовать не должен, а он есть. Тайпскрипт выводит типы и из того что написано уже заранее понятно что там undefined на выходе быть не должно. Фича в том что тайпскрипт стал лучше выводить типы, как я понимаю, а это самый наболевший пример, который очень часто проявляется. Тайпскрипт это в каком то смысле линтер и есть. Есть стадия компиляции (транспиляции), а есть стадия тайпчекинга. И компиляцию можно запустить без тайпчекинга
Автор никогда не слышал про тайп гуард? В чём проблема его добавить в функцию фильтра? Да, это условно лишний код, но и ситуация где это надо редко встречается.
filter((itm): itm is number => itm !== undefined)
Можно вот так в старом тайпскрипте. Инлайновый typeguard
Генерик версия для особо упоротых: itm is NonNullable
костыли... системой типов это решаться должно. undefined должен быть потомком всех типов, тогда и union специалььный для него не нужен. Попробуйте Elm - надеюсь, там-то хоть по-нормальному сделано.
Спасибо, полезно
"Проверка на труси"😁😁
В чем фича то?
Фильтрация происходит все же в рантайме, компайл-тайм об этом знать не должен
Автор всё доходчиво объяснил и показал! Раньше действительно была проблема, что TS не отслеживал что мы фильтруем и тип, который он вычислил вначале использовался везде. Это заставляло вставлять дополнительные проверки, чтобы можно было обратиться к объекту. Теперь с этим проблем не должно быть.
@@VitalyVasilega это должна быть проблема не языка, а статических линтеров
Как компилятор угадает рантаймовый фильтр? В сигнатурах типов указываются все ограничения, остальное - линтинг
@@kirillgimranov4943 боже мой, ts это не язык, а надстройка и статический анализатор. Как угадать? Угадывать не нужно, всё видно по AST.
Почему-то Elm может, ReScript (OCaml) может, а в ts только сейчас осилили.
@@kirillgimranov4943 C такой логикой type narrowing существовать не должен, а он есть. Тайпскрипт выводит типы и из того что написано уже заранее понятно что там undefined на выходе быть не должно. Фича в том что тайпскрипт стал лучше выводить типы, как я понимаю, а это самый наболевший пример, который очень часто проявляется. Тайпскрипт это в каком то смысле линтер и есть. Есть стадия компиляции (транспиляции), а есть стадия тайпчекинга. И компиляцию можно запустить без тайпчекинга
@@kirillgimranov4943 а в чем сложность угадать? ты же знаешь что будет возвращать этот фильтр
Автор никогда не слышал про тайп гуард? В чём проблема его добавить в функцию фильтра? Да, это условно лишний код, но и ситуация где это надо редко встречается.
капец ты быстро обрастаешь)
просто голову помыл
Всегда игнорировал такое предупреждение. Это только начинающие обращаются внимание на такое
Капец ты долгий, у purpleschool давно уже про это рассказано и намного лучше
Может ты ещё и англоязычный Ютуб предложишь чекать?🤦🏻♂️
const list = [1, 2, undefined];
list.filter((i): i is number => i !== undefined).forEach(e =>
console.log(e.toString()))