Comments 16
Как бы расстаться с Typescript, не тратить время на описание типов
Нравится читать код внутри функций?
Эмм, а зачем расставаться с typescript?
Чтобы как раньше открывать 100500 доков для разных либ и узнавать какие есть функции, что они принимают и что отдают?
Мне как-то легче описание функций смотреть в IDE, а не тратить время на то, чтобы найти доку по определенной либе.
PS. Я не имею ввиду начальное знакомство с либой, это именно про этап взаимодействия с либой.
да что уж там, если расставаться - так сразу с разработкой. там алгоритмы описывать надо
Пока что самое напрягающее для меня место в typescript это обработка ошибок.
Некоторые либы вообще не наследуют ошибки от Error, а просто выбрасывают кастомный объект с описанием ошибки. Но проблема в том, что об этом нельзя никак узнать кроме чтения кода полностью, ну или пока в рантайме не появится какая-то белиберда вместо ошибки...
Статья очень хорошая, потому что помогает сориентироваться во многих моментах, которые довольно полно описаны.
Но, по моему, зря начинать ее с таких пассажей и прививать нездоровое отношение к any:
Тип any в TypeScript по своей сути является злом и небезопасной особенностью встроенной по умолчанию в систему типов языка.
Да не является any никаким злом по сути. Именно по сути, это полезный и необходимый элемент языка. Лучше бы в ведение добавить цитату из документации:
Don’t use
anyas a type unless you are in the process of migrating a JavaScript project to TypeScript. The compiler effectively treatsanyas “please turn off type checking for this thing”. It is similar to putting an@ts-ignorecomment around every usage of the variable.
Иными словами, any это никакой не тип как все остальные, а специальный тип, потому что это элемент языка, который эффективно рассматривается компилятором как отключение типизации на месте использования.
По моему, если с этого начинать, то далее по тексту все будет восприниматься куда более ясно.
п.с.: злом, по сути, является то, что документацию по ТС до сих пор не могут нормально отредактировать, что бы все в ней было в одном месте. И сразу было понятно и для чего и почему.
Жаль, что данная статья не попалась с полгода назад, когда впервые начал писать на TS. Сколько бы нервов и матов я бы сберёг ))) Много лет писал на php, но был перерыв, в который там завезли нормальную типизацию. И тут сразу погрузился в тайпскрипт с привычкой не описывать большую часть типов. Бывало, что клаву хотелось в монитор пульнуть, со словами: "Хрен ты до меня докопался, я прекрасно знаю, какие данные будут".
Хорошо бы ещё дополнить тем как правильно прописывать типы, особенно получая динамические данные из базы, когда все не нужны и потом начинается пляска с сопоставлением.
any достаточно полезен может быть при написании библиотек, чтобы не приходилось изгаляться с ограниченными типами, которые могут быть использованы, но автор их не предусмотрел (не описал).
НО, это должно быть осознанное использование any автором библиотеки, а не "я художник - я так вижу".
"Используй unknown", скажет кто-то, но unknown - головна боль приведения типа каждый раз и не всегда это уместно, поэтому, чтобы этого избежать и пользователи сказали "спасибо", вместо мата в 3 этажа, имеет смысл указать any
А можно, пожалуйста, пример этого самого "мата в 3 этажа" при использовании unknown? Просто мне сложно представить ситуацию, в которой вместо конкретных или обобщённых типов, приходится городить непонятное нечто через any/unknown.
пример: реализовать типобезопасный debounce. Наивно сделать констреинт `(params: ... unknown[]) => unknown` функции не сработает, а вот если на `any` заменить, то все работает
Действительно типобезопасный debounce можно состряпать как-то так:
declare function debounce<P extends unknown[]>(fn: (...args: P) => void, timeoutMS: number): (...args: P) => void;
const debouncedAlert = debounce(alert, 1000);
В этом примере используется unknown, но я вроде как тут он не нарушает безопасность типов.
Функция глубокого копирования по аналогии с lodash cloneDeep, блоки catch.
Т.е. речь о ситуациях, когда нам придётся либо обвешиваться type guard, что не гарантирует что все случаи предусмотрели (человеческий фактор / неопытность разработчика), либо как раз создадим головную боль потребителю, которому ts будет ругаться, что его тип не совместим с unknown.
Например в случае с глубоким копированием, лично я, не вижу смысла делать эту функцию типобезопасной, потому что туда передать могут реально практически что угодно - в этом смысл, а следовательно и проще / дешевле для разработки использование any будет более чем оправданно.
TL;DR - если лень, то можно использовать unknown, но не any. any - зло!
Функция глубокого копирования по аналогии с lodash cloneDeep
Клонирование/копирование идеальный случай для обобщённого типа (собственно lodash cloneDeep так и типизирован с использованием generic типа)
блоки catch
Это вынужденное обстоятельство в связи с плохим дизайном ошибок в JS/TS
Т.е. речь о ситуациях, когда нам придётся либо обвешиваться type guard, что не гарантирует что все случаи предусмотрели (человеческий фактор / неопытность разработчика), либо как раз создадим головную боль потребителю, которому ts будет ругаться, что его тип не совместим с unknown.
Для новичка простительно использование any, для опытного разработчика - нет. Лучше всего использовать обобщённые типы. Если не очень хочется возится с ними, то используем unknown, который проверяется на месте или же передаётся куда-то в глубь дальше.
Например в случае с глубоким копированием, лично я, не вижу смысла делать эту функцию типобезопасной, потому что туда передать могут реально практически что угодно - в этом смысл, а следовательно и проще / дешевле для разработки использование any будет более чем оправданно
Кто-то ведь копирует данные, значит должен знать как это делать, значит должен располагать информацией о типе копируемого значения, следовательно какая-то информация о типах имеется.
О чем и речь: any - зло, если только на проекте, которым можно полноценно управлять.
Если мы говорим о внешних зависимостях, то any вполне применим, т.к. типобезопасность ts - миф и легко обходится, да и сам ts тупит нормально и, порой, только костылями его можно заставить думать как хотим мы.
p.s.
хоть речь не о нем, а лишь в качестве примера, тот же cloneDeep, когда я смотрел последний раз, был на js и в jsDoc у него был указан аргумент как * - any
Расстаемся с any в TypeScript