Перевод статьи подготовлен для студентов курса «Разработчик JavaScript» в образовательном проекте OTUS.
Вот так не успеешь обернуться, а месяц уже стремится к своему завершению. Считанные дни остаются до запуска нового потока по курсу «Разработчик JavaScript», по традиции перед запуском курса делимся с вами переводом полезного материала.
Vanilla JavaScript не типизирован по своей натуре. Можно даже назвать его «умным», поскольку он способен вычислить, что является числом, а что строкой.
Это упрощает запуск JavaScript кода в браузере или при работе Node.js. Однако он уязвим для многочисленных ошибок во время исполнения (рантайм), которые могут испортить ваш пользовательский опыт использования.
Если с вами когда-либо случалось то, что будет описано далее, то вы только выиграете, если будете применять систему типов.
- После получения списка данных вы обнаруживаете, что определенное поле не существует в одной из записей. Это приводит к сбою в работе приложения, если этот случай не отлавливается и не обрабатывается явно.
- Экземпляр класса, который вы импортировали, не имеет метода, который вы пытаетесь вызвать.
- Ваша IDE не знает, какие методы и свойства доступны для модулей и библиотек, поэтому она не может эффективно предлагать автодополнение.
Flow, TypeScript или ReasonML
Скажем, у вас есть существующая база кода, которую вы хотите сделать более надежной и стабильной. Принимая во внимание существующие ошибки типизации, вы можете попробовать применить для этого Flow или TypeScript (они имеют достаточно сходный синтаксис).
С другой стороны, применение каждого из этих громоздких инструментов дело сложное. Вы загрузите себя работой, связанной с созданием типов и интерфейсов для кода, которые не были ранее разработаны.
И тем не менее Flow и TypeScript не дают 100% безопасности при добавлении типизации в коде.
По этой причине идеальная безопасность типизации достигается посредством вывода и делает аннотирующие переменные и сигнатуры функций более простыми.
Простые и явно надуманные примеры
Рассмотрим следующий код:
В обычном JavaScript эти аргументы могут быть числами или строками. В TypeScript или Flow эти аргументы могут быть аннотированы как:
Теперь мы видимо задаем именно два int значения. Не два float или два string, для их операций сложения используются другие операторы.
А теперь давайте взглянем на чуть измененный пример в Reason:
Эта функция работает! И это может показаться удивительным. Каким образом Reason это понимает?
Эта функция имела недостатки на уровне реализации. У Reason есть разные операторы для сложения int, float и string.
Цель этого простого примера – показать, что вполне возможно иметь лишние «ошибки» типов, даже если это не роняет приложение.
В программе на Reason разработчикам не приходится разбираться с багами на продакшене, которые возникают из-за несовместимости типов или null значений.
Опыт разработчика
Одна из самых приятных особенностей в TypeScript – это то, что вы видите предложения по улучшению или автозаполнение в редакторе кода.
Это одна из областей, где TypeScript имеет преимущество над Reason, поскольку программа на TypeScript не должна быть скомпилирована идеально, чтобы предложить автозаполнение. Reason же заставит вас исправить все ошибки в синтаксисе и типах, перед тем, как предложить вам полезное исправление.
Так это работает в VSCode, но я знаю много Reason разработчиков, которые используют vim. Здесь мы не будем углубляться в сравнения.
Несмотря на то, что я большой фанат Reason, также я писал приложения на TypeScript или Flow. Волна хайпа вокруг TypeScript дает хороший стимул, чтобы выбрать именно его, поскольку из-за этого он имеет большую поддержку комьюнити.
С другой стороны, Reason сложнее использовать, поскольку для него доступно меньше статей и документации. Надеюсь, с его развитием это исправится.
Если Reason вас заинтересует, вы можете найти здесь его документацию. А еще подпишитесь на таких личностей, как @jordwalke, @jaredforsyth и @sgrove в Твиттере. Они многое могут рассказать об экосистеме Reason/OCaml.
Если же вы захотите узнать, как Reason работает с GraphQL, обратитесь к другой моей статье «Reason with GraphQL, the Future of Type-Safe Web Applications».
Ждем отзывы о материале и приглашаем всех читателей на день открытых дверей, который 25 марта проведет наш преподаватель — Александр Коржиков.