Моя идеология работы с TypeScript

Надо писать на JS с типами, а не превращать код в C#

Зачем нужна типизация в JavaScript?

Без нее JavaScript хорошо жил на протяжении более 20 лет. Но раньше на JS не решались сложные задачи мега уровня (энтепрайз, банки и все такое…). Сейчас этот язык вышел за пределы браузера и зашел на территорию бэкенда, десктопных приложений, расширений для браузеров и мобильные устройства, интернет вещей (IoT), к примеру микроконтроллеры https://tessel.io.

При написании большого приложения становится сложно отлавливать ошибки, которые часто связаны именно с приведением типов.

TypeScript

Да — это помощь. Хотите чтобы JavaScript превратился из языка с динамической неявной типизацией в язык со строгой явной динамической тпизацией? Тогда выбирайте TypeScript. Да, он делает разработку сложнее, если вы не работали никогда с явными строгими типами.

Так после компиляции типов не будет же…

Открою секрет, но в языках типа Java типы проверяются компилятором на этапе компиляции, а в runtime нет никаких проверок. И если у вас придет неверный тип — программа выкинет исключение (если вообще не упадет (ну вы же готовы к этому и обработали исключение ☺)).

Моя идеология работы с TypeScript

TypeScript — это JavaScript с опциональной типизацией. Не надо превращать ваш код в C#. Все должно быть в разумных пределах. Если вам нужно разработать продукт быстро и вчера, то вы пишете на TypeScript как на обычном ES6+, и используете примитивы или несложные интерфейсы. Когда ваш MVP взлетел и вы поняли что готовы развивать его, вы выделяете время на рефакторинг и уже описываете типы серьезно.

Описывать типы важно для вашего кода! Все что в node_modules мы считаем черной коробочкой. Если хочется крутой типизации и крутых подскзок в IDE, ставим декларации (d.ts файлы) через утилиту typings.

Если у вас проблемы при работе с типами от сторонних библиотек (React.d.ts, Moment.d.ts, …) то есть два пути:

  1. Залезть в файл и исправить ошибку в декларации (да да, все эти декларации пишут люди, порой вообще никак не связанные с проектом)
  2. Написать свои декларации заглушки
declare module "React";

И уже по мере работы, находя свободное время, расширять декларацию-заглушку до нормального состояния. Таким образом вы даже освобождаете себя от “вендор-лока”. Что будет если выйдет новая версия React? Кто будет править (и главное, когда) d.ts файлы?

За use’ал библиотеку, а там нет d.ts файлов ☹

Да, такое бывает. Например я решил использовать Redux-Elm. Как быть?

Ищите файлы с расширением .flow. Если вдруг нашли, вам повезло. Хоть синтаксис Flowtype отличается от TypeScript, все же вам будет проще переписать это на TS. Так я и поступил.

Так выглядит Flowtype декларация (оригинальный файл имел имя index.js.flow)

А так выглядит переписанная за 5 минут декларация на TypeScript:

TypeScript вариант, переписанный с Flowtype

Исходники можно взять с Github https://github.com/frontdevops/redux-elm-typescript

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

declare module "redux-elm";

И уже постепенно описывать по 1й функции, которые используете.

Хочу проверку типов в runtime

Тогда нужно что-то вроде RTTS (RunTime Type System). Я сделал такой пакет ради академического интереса (но не финализировал его). Этот NPM пакет добавляет в проект аннотации типов через декораторы и делает проверку прямо в runtime. Если у кого-то есть интерес к RTTS, предлагаю присоединиться и реально его довести до финала.

Давайте общаться

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

А еще я предлагаю посмотреть доклад Grigory Petrov в продолжении темы:

Grigory Petrov: “Type: Python vs Typescript”