Самые частые ошибки в TypeScript
HTML-код
- Опубликовано: 6 июн 2024
- Не надо так делать! Этих ошибок можно избегать при работе с TypeScript.
Не согласны? Пишите в комментариях свои версии 😎
⚡ Мои курсы
Курс по TypeScript: purpleschool.ru/course/typesc...
Все мои курсы: purpleschool.ru
Telegram канал с полезными советами: t.me/purple_code_channel
Разделы видео:
0:00 - Введение
0:10 - Strict режим
3:16 - Приведение к типу
5:15 - Optional параметр
6:38 - Числовые enum
8:33 - Название Generics
9:30 - Заключение
Спасибо, очень полезно, я не новичок, но почерпнул кое-что для себя!
Продолжайте!
Спасибо!
Спасибо за видео!Полезно.
Пожалуйста)
TKey, TValue хорошая тема. Зачастую в крупных проектах люди даже не задумываюсь городят женерики через K,T,V. Нередко видел сложные кейсы с 7-8 латинскими буквами. А тут довольно очевидный способ упростить себе жизнь. Даже как-то неловко, что за все то время, что я работал с TS мне и в голову не приходило, что так можно сделать. Спасибо!
Рад, что видео было полезно)
Числовые енумы еще и менее типобезопасны. К перечислению из видео можно обратиться Role[123] и тайпскрипт не ругнется на это. Ну и если параметр функции имеет тип числового енума, то в неё можно передавать любое число
Совершенно верно!
Очень полезный видос, новичкам - в особенности!
Спасибо!)
Спасибо!
Пожалуйста)
Спасибо большое за видео !!! Очень познавательно и понятно!
Пожалуйста!
Хотелось бы заметить, что не в первом видео у многих популяризаторов TS вижу отсутствие возвращаемых типов в методах/функциях. А это очень важный пункт, особенно для "отдельно стоящих" функций. Так вы на уровне написания кода "гарантируете" себе, что собираемый ответ функции будет совпадать по типу с тем, что ожидается, потому что иначе будет результату назначен тип ответа, и не факт, что он будет совпадать с ожиданиями клиентов метода/функции.
Поддерживаю что писать возврат желательно, можно даже настроить eslint правило, но иногда бывает overkill, особенно для данных из базы. Поэтому сам не всегда следую.
Иногда в контексте уже просто ясно что за тип и тайпскрипт сам забирает этот тип
но молодняк лучше учить его писать. Помогает растить архитектурное и контрактное прогание)
Да, я тоже нашёл для себя полезные моменты))
Супер)
ICatFact читаешь как IGetFucked ахаха. А видос хороший, спасибо!)
))
enum в TS,как goto в тех языках, где он есть: тебя учат его не юзать. Ты находишь 1-2 крутых применения. Учишь не юзать) Учитывая, что есть перечисляемые строки иногда enum очень вредит) особенно в json схемах. А к ним всё сводится в API)
Антон, как считаете в ближайшие 2-3 года главные фичи тайпскрипта войдут в джаваскрипт через новые пропоузелы?
Что-то войдет, что-то нет.
Зачем нужны енамы в современном тайпскрипте?
Просто используйте const объект с записью as const после определения.
Скажите, пожалуйста, какой шрифт вы используете?
AIWriter Mono
@@PurpleSchool Спасибо)
Подскажите, а может быть у вас есть разбор того как правильно объявить типы для библиотеки (публикуется как npm) в одном файле так, чтоб эти типы были доступны в проектах использующих её как зависимость.
Интересно как базовое решение так и вариант когда библиотека состоит из модулей которые можно импортировать отдельно
import { auth, log } from 'my-pkg';
import auth from 'my-pkg/auth';
import log from 'my-pkg/log';
Спасибо.
Есть про типизацию сторонних библиотек в курсе по TypeScript, про публикацию типов нет.
@@PurpleSchool Вот про типизацию сторонних библиотек много где есть и там в общем всё вроде бы более менее понятно. А вот как для своего пакета правильно d.ts сформировать что-то как-то мало информации.
Но в любом случае спасибо.
Что думаешь про strictNullCheck?
Обязательно нужен)
7:00 в чем смысл строковых enum, если имя и значение одинаковые? Просто написать enum, ради enum? Гораздо лучше в этом случае перечислить в типе все возможные значения через union.
А (const) enum как раз и нужны для того, чтобы сделать человекочитаемое название для примитивного значения, такого как number.
Например, я часто использую const enum для описания битовых флагов и масок.
Смысл в том, что бы когда ты писал условный Role.student, это высвечивалось списком доступных ролей, а если написать обычной строкой, может быть ошибка и undefined вылезти какой-то
@@user-jf2ui2qy1y почему "обычной строкой", если я написал: "через union"? И подсказки будут работать в IDE и типизация строгая.
параметр по умолчанию, думаю, можно к ошибкам js в целом отнести, а не ts)
Тоже верно
@@PurpleSchool а так да, спасибо за видео, полезно было
Чую след C# 😁
Так один и тот же человек проектировал эти языки)
Что за тема в vscode ?
Bearded Theme Vivid Purple
а зачем аксиос , еси фетч есть?
Более удобный как по мне
05:03 Вот как по мне в это и проблема TS тут хоть как не крути на выходе будет не пойми что, но зато мы используем TS ... Очень много мест в коде и библиотеках в которых мы все равно не будет знать что там будет за тип, а только предполагать, эх ...
Не очень понял. Если мы все верно типизируем, то мы можем не знать только приходящие извне данные. И такая же проблема будет и в Go и в C#. Все равно нужно валидировать все входящие данные
@@PurpleSchool валидировать то понятно, но вот в данном случае axios при указании джинерика не делает валидацию что data является типом что мы указали а просто надеется на то что он им будет в C# если тип не будет соответвовать джинерика будет ошибка, тут нет потому что TS это по-сути кодогенератор и не принимает участия в выполнении кода, отсюда и проблемы с дженериками в TS. Отсюда и написал что мы надеемся что data будет тем самым что мы туда передадим. Просто плохой пример с axios :)
Конечно, он просто позволяет описать тип. Валидацию мы должны сделать руками
Это проблема JavaScript, которую TS не решает, т.к. не может решить в принципе. Просто не нужно ожидать того, чего нет. Кстати, не вижу никакой проблемы сделать валидатор, который в рантайме будет проверять соответствие ответа сервера ожидаемому типу. Кстати, таких валидаторов есть, и не мало.
@@user-vu6hn4ul2i "Кстати, не вижу никакой проблемы сделать валидатор, который в рантайме будет проверять соответствие ответа сервера ожидаемому типу" - Да, такое подходит в случае если мы говорим об запросах на сервер, но отсутствие нормальной кодогенерации, крайне ограничивает во всех других случаях, когда с помощью нее можно было бы сделать более удобный библиотеки и оптимизировать код.
Например, написать тот же валидатор лишь с помощью типов, как пытаются сделать с помощью TS+
Пример с типизацией дженерика axios вместо as ни на что не влияет и ни от чего не защищает. Если нужна проверка входных данных - есть валидация по json схеме. Ну или обычные if-ы.
Конечно. Тут point в том, чтобы использовать данные библиотеками Generic для верной типизации, а не грубо приводить к типам
@@PurpleSchool вангую что под капотом происходит примерное тоже самое. По сути просто код стал красивее и короче
ну то есть, что мы указали в дженерике тип, что привели через as - в любом случае мы точно не знаем, придем ли нам данные указанного типа или нет? И нужна именно проверка входящих данных
Скажите пожалуйста что за тема?
Bearded Theme Vivid Purple
Enum'ы крайне полезны, когда кто то написал бек г*внокодом и юзает там же дефолтные значения.
Не знаю крайне не согласен про запись в БД строкового значения, все таки для БД гораздо эффективнее писать числа.
Зато эффективнее потом вытаскивать из базы и анализировать строки, а не магические значения. Особенно актуально, если с базой работают не только разработчики, но м аналитики.
по звуку рассинхрон?
Вроде нет
@@PurpleSchool все отлично, большое спасибо за видео
Пожалуйста)
В середине ролика нормально склоняешь Тайпскрипт (в Тайпскрипте, Тайпскриптом, по Тайпскрипту), но в самом начале и самом конце ролика почему-то не склоняешь -- смотрите другие видео по Тайпскрипт... По чему? по Тайпскрипту, а не по Тайпскрипт. В общем, не нужно бояться склонять слова в русском языке.
Комментарий ни о чем)
Так забавно видеть как вы рассказываете об ошибках TS, но при этом не указываете возвращаемые типы для функций.
После этого я не верю в то, что вы действительно правильно используете TS. Как будто вы пытаетесь, но на автомате продолжаете мыслить как JS.
В целом ваши советы правильны, но на мой взгляд слишком тривиальны.
Забавный выводов основании не указания возвращаемых типов) я как раз на JS чистом почти никогда не пишу, только TS, Go, C#, где везде типизация
@@PurpleSchool Тогда странно, что вы не пишите возвращаемые типы, ибо тогда и вопроса про cast из видео не возникло бы - когда вы бы убрали "data as T", то автоматом увидели бы ошибку, а не any по-умолчанию. А так вы дженериком решаете не проблему, а последствия.