TypeScript - фатальные ошибки!

Вы когда-нибудь задумывались о том, какие ошибки чаще всего допускают в TypeScript? Я нет, но кажется пора бы задуматься, годы то идут...

0:00 Пролог
00:51 Миллион и еще 1 одинаковый тип
04:05 Как .Net подпортил нам малину
05:10 Бежим от Function и any
05:45 Извиняюсь за ReturnType
07:26 Тотальная перегрузка
07:58 Закрываем типы на замок
09:17 Резюме
________________

Один из моих самых любимых каналов о Фронтенде в telegram:

________________

Утилиты TypeScript

Почему не стоит использовать префиксы

________________

Материалы, которые я использовал для подготовки видео:

Спасибо авторам!

#TypeScript #JavaScript #frontend

[it]

Тренажеры HTML Academy (HTML, CSS, JS, React) + Академия + Книга рецептов фронтендера + комьюнити
за 99 рублей:

Какие тренажеры бывают:

Подписывайтесь:



Друзья, в комментариях последнего выпуска развернулись нешуточные баталии!
И это круто! Прочитал все споры и претензии с удовольствием. Но сейчас хочу прокомментировать несколько моментов.

Претензия #1. Очень много комментаторов отстаивают префикс I в интерфейсах.

Тут мне осталось прикрыться стайлгайдом Майкрософта.
Уже очень давно не видел тайпинги к библиотеками с префиксами в интерфейсах.

Остальные же причины уже озвучены в видео и к ним мне добавить нечего.

Претензия #2. Ты что дурак? Вместо того, чтобы использовать утилиты для маппинга типа можно использовать наследование.

Да, это правда. И мне жаль что в видео тема наследования не была раскрыта.
Конечно же можно было бы решить задачу наследованием. Но тайпскрипт на данный момент идет к Mapped Types.

1) Наследование создает самую сильную связь и в программирование есть рекомендация стараться избегать наследования любой ценой, ибо архитектура, построенная на наследование очень тяжело адаптируется к изменениям. Я понимаю, что это еще более холиварная тема. Однако Майкрософт выбрал вектор Mapped Types и если вы почитаете исходный код Ангуляра или того же Тайпскрипта, то повсюду будете встречать именно утилиты вместо наследования.


Претензия #3 Утилиты убивают читабельность.
Я бы не сказал, что прям так убивают. Но претензия резонна. Проблема в том, что Mapped Types утилиты так выглядят, потому что они дженерики и по-другому проблему было бы не решить (наверное).

С другой стороны думаю комьюнити TS просто еще к ним не привыкло. Возможно сейчас стадия неприятия незнакомого, поэтому столько критики.

Стоит добавить, что читабельности поможет разбивание типов на подтипы, как вот тут NonAnonymousBook и CarModel

Спасибо всем кто оставлял комментарии! Я прям удовольствие получаю, когда читаю все эти споры!

[Consanine]

Совет по наследоваю/выведению в чистом виде может быть крайне опасен, так как зачастую во имя DRY начинает расти зацепление(coupling) всего от всего, хотя семантически сущности абсолютно разные.

[dmitryrockstar]

Пример с Book и Article неправильно подобран, ибо Book и Article фактически две отдельные сущности. Если в сущность Book позже добавятся поля, которые не должны быть в Article то Omit их оставит и это приведет к ошибкам

[arsenymedoev]

Хотел увидеть фатальные ошибки TypeScript, а увидел фатальные ошибки разработчиков

[mmospanenko]

Давай больше подобного, не всегда приходится сталкиваться с подобными фишками а без контекста это не так воспринимается с доки - лайк/подписка)

[max_mgtow]

Приветствую бро 🤝👍
Всё очень круто) Всегда жду роликов

[SergioUkrAr]

Супер, контент на высшем уровне, спасибо).

[it]

Алярм в выпуске есть фатальный косяк на 3:41
Вот


Твой Лайк и подписка спасут интерфейс Cat!

Один из моих самых любимых каналов о Фронтенде в telegram:



0:00 Пролог
00:51 Миллион и еще 1 одинаковый тип
04:05 Как .Net подпортил нам малину
05:10 Бежим от Function и any
05:45 Извиняюсь за ReturnType
07:26 Тотальная перегрузка
07:58 Закрываем типы на замок
09:17 Резюме


Утилиты TypeScript

Почему не стоит использовать префиксы



Материалы, которые я использовал для подготовки видео:

Спасибо авторам!


#TypeScript #JavaScript #frontend

[EasyITChannel]

Инструкция как максимально осложнить жизнь новым разрабам после ухода автора кода. Ну или как сделать себя незаменимым на проекте :)
Все сказанное интересно в общеобразовательных целях или как челлендж, но на крупном реальном проекте лучше все делать очевидно и чем проще тем лучше. Чтобы для чтения кода не нужно было сидеть в обнимку со справочником по языку.
В любом языке много интересных конструкций, которыми вовсе не обязательно пользоваться. Для очевидности кода лучше сделать два интерфейса отличающихся одним полем, чем использовать что-то экзотическое.

[yurakhomitskyi]

Утилиты норм когда у тебя маленькие интерфейсы, но иногда надо 10 ключей взять, и несколько убрать. И эти вложенные утилиты читать сложно. Думаю лучше делать базовые интерфейсы и наследоватся

[kirills]

2:20 я бы здесь использовал композицию для интерфейса книги вместо утилити типов для статьи, мне кажется такой подход позволяет лучше проработать интерфейсы бизнес сущностей, повышает читаемость и упрощает расширение

[Eugene.g]

Сорри, но шо-то ересь какая-то. Pick и пр утилиты с точки зрения читаемости кода - ужас, по-моему они сделаны для того чтобы писать в ФП стиле т.к. в ФП есть and, or типы. Interface существует вообще для другого, это контракт, а не описание типа. Чтобы не повторяться, есть принцип разделения интерфейсов

Префикс i ни как не нарушает инкапсуляцию и я не припомню, чтобы хоть раз я переделывал интерфейс в класс

По поводу иммутабельности тоже ерунда. Она нужна только если мы пишем в ФП, в ООП мутабильность - благо, просто нужно защищать стейт объекта, например, при помощи геттеров и сеттеров, для этого и нужна инкапсуляция

[Glotka]

А потом эти утилитарные типы превращаются в 3х строчных малочитабельных монстров, где тронь одно и повалится все как в начале видео. Расширить или как то поправить базовые типы будет проблематично т.к. все правки придется вносить и в те же утилиты Pick и Omit, где они не нужны или наоборот нужны.
Мое имхо что это все конечно прекрасно, но лучше пусть у меня будет 100500 похожих раздельных типов чем каша из 3-4 статичных типов и утилит.

[AbraKadabra]

3:31 жесть нечитабельная. Какой-то недо'хтмл. А главное уде на этом этапе хочется начать поиск альтернативных, простых решений

[AOne]

Зашел чисто лайк поставить за труд. Потом посмотрю)

[tanercoder]

пожалуйста еще такого же контента и много сразу!

[Max-nrbv]

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

[MrWerwoolf]

Лайкнул, подписался, не первое видео смотрю у вас.

[devereg]

5:44 Возвращаемое значение функции будет unknown, хотя мы точно знаем что оно будет таким же как у колбека который мы передали.
Выглядит так как будто можно было использовать дженерик и все бы прекрасно типизировалось (дженерик прописывать явно при вызове не нужно, он сам распознает исходя из переданного колбека)

[akatsukinoyami]

Второй пример в первой секции (там где Required + Omit), разве не проще сделать так?

interface NewInterface extends OldInterface {
author: string;
}

Это и сохранит старые поля, и сделает нужное поле обязательным, но выглядит проще и читабильнее.