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()))