Недавно я спроектировал и разработал небольшое приложение javascript с использованием React и Redux. Услышав, как многие мои коллеги все больше и больше говорят о Flow и Typescript, я понял, что хочу попробовать один из этих вариантов. В итоге я выбрал Flow. В то время я полагал, что Typescript - это комплексный подход, в то время как Flow казался чем-то, что я мог бы вводить постепенно (о, как я ошибался!)

После завершения первоначального MVP я увидел много преимуществ от использования Flow, но меня также отпугнули несколько проблем. В следующем проекте, который я начал, я использовал Typescript и сразу влюбился, поэтому, когда я повторно посетил свой проект Flow, я реорганизовал его в Typescript (он был достаточно маленьким, что потребовалось всего полдня).

Это классическое приложение React / Redux с единственным файлом, описывающим состояние. Приложение было простым - оно представляет пользователю вопрос и регистрирует ответ на выбранный ответ. Я решил использовать ImmutableJS Records для описания моего состояния, потому что мне очень нравится, что они действительно неизменяемы, но позволяют вам получить доступ к свойствам, как к любому объекту javascript.

Штат

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

Поток

Машинопись

Какие преимущества я получаю от определения типов вместе с моим состоянием?

Мое состояние четко передано и задокументировано в моем коде.

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

Я не могу (случайно) неожиданно изменить состояние

В моем редукторе, если я неправильно написал свойство при изменении состояния, Typescript сообщит мне:

Действия

При отправке действия вы хотите убедиться, что отправляете только те действия, которые ожидаются. В вашем редукторе вы хотите обрабатывать только ожидаемые действия.

Поток

Машинопись

Какие преимущества вы получаете, определяя свои типы, как в приведенном выше примере?

Тип безопасности в вашем редукторе

Если вы попытаетесь обработать действие, которое не определено, Typescript сообщит вам об этом.

Мои мысли о Typescript vs Flow

Я хотел коснуться того, почему в этом приложении я перешел с Flow на Typescript.

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

Что касается Flow, я считаю, что это хороший инструмент, но с ним трудно работать. Что я имею в виду? Я обнаружил, что интеграции с VSCode (или любой другой IDE) не хватает. Когда я написал фрагмент кода, нарушающий правило, иногда через 10–20 секунд после факта, мне казалось, что Flow медленно откликается на ценные отзывы. Это приводило к надоедливой погоне за хвостом. С другой стороны, интеграция Typescript с VSCode быстрая. Я чувствовал, что среда IDE сразу же ответит на вопросы, когда я буду печатать.

Flow дает вам хороший инструмент, который показывает покрытие кода, но в конце концов он меня больше расстроил, чем помог. В душе я завершитель, поэтому такие зеленые линии в моей кодовой базе сводили меня с ума.

Наконец, похоже, что у Typescript гораздо лучшая поддержка сообщества, чем у Flow. Я использовал glamorous и glamor в этом проекте для рендеринга компонентов пользовательского интерфейса, и для библиотеки нет определений потокового типа, но есть для Typescript. Это обычное дело для многих библиотек, которые используются часто, но не повсеместно.

Спасибо, что прочитали мою статью. Вы предпочитаете одно другому? Почему? Напишите в комментариях ниже!