Почему я считаю важным предложение о необязательном и стираемом синтаксисе типов в JavaScript.

Сегодня вы можете обнаружить синтаксис типов в большинстве популярных языков. Java, Dart, Rust и языки C — это несколько языков, которые требуют стандартного синтаксиса типов. Такие языки, как Kotlin, Swift и Go, либо имеют выведенный тип, либо вы можете вывести тип явно. Даже Python, который известен своей дружественностью к новичкам и отсутствием синтаксиса статической типизации, разработал типизацию, начиная с версии 3.5¹. Синтаксис типов в последнее время набирает популярность.

Я не буду вдаваться в особенности синтаксиса строгого/слабого и статически/динамического типов, поскольку основное внимание в этой статье уделяется важности синтаксисов типов в целом.

Конечно, синтаксис типов нравится не каждому разработчику. Некоторые могут возразить, что необходимость иметь дело с синтаксисом типов в их коде замедляет процесс разработки, особенно если у вас сжатые сроки или вам нужно запустить MVP в производство, синтаксис типов может быть недостатком для вас и вашей команды. Необходимость постоянно следить за тем, чтобы ваши значения не были присвоены переменной другого типа, может раздражать во время выполнения, а необходимость вводить больше кода просто не доставляет удовольствия. Есть те, кто утверждает, что синтаксис типов в их коде не нужен, если вы пишете чистый код. Удобочитаемость также является причиной, по которой некоторые разработчики предпочитают синтаксисы с выводом или динамической типизацией по сравнению со статически типизированным синтаксисом.

Почему я люблю TypeScript

В настоящее время JavaScript поддерживает что-то похожее на синтаксис типов. Если вы используете VSCode, вы можете добавить документацию по типам с комментариями JSDoc, а затем использовать комментарий @ts-check для проверки кода.

// @ts-check
/**
 * @param bar {number}
 * @returns {number}
 */
function foo(bar) {
  return bar
}

Этот метод документирования немного утомителен и не нужен мне. С другой стороны, TypeScript ведет себя аналогично Java и C, где требуется объявление типа переменной в объявлении переменной и/или параметрах, а иногда и в возвращаемом типе. Поэтому я думаю, что нет необходимости добавлять документацию, подобную той, что приведена выше.

После первой стажировки я увидел, что TypeScript набирает популярность² в сообществе разработчиков, и решил начать его изучать. Ведь большая часть моей работы, если не вся, так или иначе связана с JavaScript. Так что изучение TypeScript было лишь второй натурой.

Я думаю, большинство согласится, что function foo(bar){} намного легче читать по сравнению с чем-то вроде function foo(bar: string): void{} (а для тех, кто использует Java, public static void main() может показаться немного избыточным для тех, кто не знаком с Java😂). И я думаю, что это также причина, по которой некоторым разработчикам не нравится иметь какой-либо синтаксис типов. Очевидно, что не весь код компании так же прост, как foo и bar, но по мере того, как репозитории становятся больше, сложность проекта может стать менее читабельной.

Когда дело доходит до тестирования с помощью TypeScript, я считаю, что это устраняет избыточность некоторых тестов. Я думаю, что тестирование типов переменных теперь излишне, когда я переключился на работу с TypeScript. Каждый раз, когда я компилирую свой код TypeScript, он в значительной степени выполняет мини-тест всего моего проекта перед развертыванием и сборкой в ​​​​производственной среде. На самом деле, VSCode сообщит мне об ошибке еще до того, как я попытаюсь его скомпилировать. Когда я работал с JavaScript, тестирование типов переменных было повторяющимся и пустой тратой времени. Если в вашем коде уже есть синтаксис типов, вам не нужно тестировать типы переменных.

Конечно, есть некоторые исключения при тестировании типов переменных, т. е. когда переменные имеют несколько типов или имеют пользовательские типы.

Использование синтаксиса типов в вашем коде предотвращает некоторые ненужные мутации переменных. Я работал с разработчиками, которые постоянно использовали var или let в своих объявлениях переменных JavaScript, и меня действительно бесит, насколько легко изменять эти переменные. Я практикую (или, по крайней мере, пытаюсь) отраслевые стандарты написания кода с работы на сторонние проекты, так что написание «хорошего» кода стало для меня второй натурой. Вот почему мне нравится использовать TypeScript, он заставляет других разработчиков нести ответственность за то, что они пишут.

Почему это важно для меня

В моем опыте работы над множеством различных типов проектов и переключения между TypeScript и JavaScript я столкнулся с одной проблемой, которая сводила меня с ума… когда переменная потенциально равна нулю или не определена, и вам нужно добавлять eslintignore везде, где она встречается….

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

Предложение по необязательному синтаксису в основном такое, как оно написано. Это необязательно. Идея предложения состоит в том, чтобы исключить процесс переноса из TypeScript в JavaScript для браузера и сделать синтаксис типов частью JavaScript. Это устраняет барьеры для многих разработчиков и команд, которые хотят переключить или перенести свои репозитории JavaScript на TypeScript!

Я думаю, что это также весьма полезно для многих разработчиков, которым нравится тестировать свой код на JavaScript, прежде чем переводить его на TypeScript. Я довольно часто делаю это при создании новых компонентов или функций с нуля.

Мои опасения

Одна из моих главных опасений по поводу результата этого предложения заключается в том, насколько необязательным будет этот «необязательный» синтаксис. Смогут ли разработчики использовать частичный синтаксис в своем коде (например, function main(str: string, num): void {})? Сколько ошибок и устранения неполадок произойдет во время его первого первоначального выпуска? И как другие библиотеки и пакеты будут взаимодействовать с этими изменениями?

Ребята, что вы думаете?

Ресурсы

Если кому интересно читать дальше, то заходите сюда:

Источники

¹ Документация на языке Python

² На основе Состояние Octoverse в 2021 году от GitHub и Состояние экосистемы разработчиков в 2021 году от JetBrain.

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку. Подпишитесь на нас в Twitter, LinkedIn, и Раздор.