React - использование TypeScript vs Flow vs?

Я собираюсь начать этот ответ, сказав, что я никогда не использовал Flow, поэтому я не могу сказать об этом много. Но мы используем React и TypeScript в работе, и они отлично работают.

У нас есть все преимущества, о которых, как я полагаю, вы уже знаете, такие как рефакторинг, безопасность типов, автозаполнение и т. Д.

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

Что касается технологий, я бы сказал, что TypeScript - беспроигрышный вариант, Microsoft продвигает язык (будет версия 2 скоро), Angular также использует его, и есть много разработчиков Angular. Даже здесь, на SO, у тега TypeScript более 4К последователей, и редко остаются вопросы без ответа.

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

Я просто задал себе тот же вопрос (но не с React) и нашел следующие статьи, полезные при оценке этих двух:

• http://michalzalecki.com/typescript-vs-flow/ (2016-07-15 )
• https://blog.wearewizards.io/flow-and-typescript-part-2-typescript (20.11.2015)
• https://blog.wearewizards.io/flow-and-typescript-part-1-flow (13.11.2015)

Подход, применяемый проектировщиками потока, кажется более функциональным с лучшим выводом типов и лучшим подходом для нулевых значений. Тем не менее, TypeScript имеет лучшую поддержку сообщества, особенно в отношении добавления типов для сторонних библиотек через http://definentytyped.org/ что важно для того, чтобы типы проходили через весь ваш код для максимальной безопасности типов. TypeScript создан Microsoft, который имеет богатую историю написания компиляторов и развития технологий в благоприятных направлениях - примечательным здесь является C # и тот факт, что они уже добавляют ненулевые типы (2016-07-11): https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

TypeScript кажется сегодня более безопасной ставкой.

А для тех, кто пробует TypeScript в существующей кодовой базе, я обнаружил, что следующие настройки в моем файле tsconfig.json действительно полезны, позволяя TypeScript сосуществовать с JavaScript (позволяя переходить по одному файлу за раз):

{
    "compilerOptions": {
        "allowJs": true,
        "isolatedModules": true,
        ...
    }
}

В моей разработке на React у меня есть довольно сложный Babel / Webpack / Flow / Набор инструментов Mocha настроен и никогда не имел проблем с Flow. Требуется некоторое усилие, чтобы все настроить (сначала Webpack может показаться сложным), но потом он просто работает. Flow, безусловно, лучший вариант, так как это более узкая и сфокусированная технология, которая, скорее всего, будет хорошо работать с другими инструментами. Напротив, TypeScript пытается быть чем-то большим, чем просто инструментом вывода типов / проверки статических типов, и поэтому приносит дополнительный багаж и допущения. Итак, React - это специализированный инструмент, который хорошо справляется с одной задачей, в то время как TypeScript - это, по сути, язык, расположенный поверх JavaScript. Чтобы Microsoft добилась своего, файлы TypeScript обычно имеют другое расширение (.ts вместо .js), потому что теперь вы используете другой язык, понятно?

TypeScript использует генерацию кода для вывода JavaScript, тогда как в Flow аннотации просто удаляются, генерации кода как таковой нет. В прошлом люди из Microsoft, продвигающие TypeScript, делали заявление о том, что генерация кода выполняется «локально для файла» (я не помню точную используемую терминологию). Это должно было дать успокаивающее заверение в том, что компилятор TypeScript не делает ничего слишком волшебного. Во всяком случае, я больше не могу найти это утверждение на видном месте. С Flow вам не нужны такие гарантии, поскольку вы пишете на простом JavaScript (или в любой другой версии ECMA, для которой вы настроили Babel), а аннотации, как я уже сказал, просто удаляются.

Не говоря уже о том, что TypeScript исходит от компании, которая специализируется на неэтичных и сомнительных технических приемах (я не исключаю, что TypeScript может в конечном итоге оказаться матерью всех уловок Embrace-Extend-Extinguish). Не будем забывать, что Microsoft сделала все возможное, чтобы вызвать сбой Javascript, поскольку они (справедливо, хотя и с опозданием) предвидели, какую угрозу он представляет и продолжает представлять для их дрянной операционной системы и их раздутого офисного пакета.

Кроме того, система типов Flow была намного мощнее, когда я последний раз оценивал TypeScript (около 2015 г.), и было намного проще применять ее постепенно или даже время от времени в исходных текстах. Для интеграции сторонних библиотек я использую flowtyped, и мне очень редко нужно дополнять их нашел там с моими собственными определениями.

Наконец, тот факт, что Angular использует TypeScript, абсолютно ничего не значит, поскольку Angular не очень актуален для новых проектов. React победил, пора двигаться дальше.

Если вам нужны проверки типов, но вы бы предпочли сохранить старый простой javascript (чтобы избежать компиляции или для переносимости и т. Д.), Вот одно важное различие между ними (для React или в целом):

• With Flow the initial setup can run static analysis on vanilla js (it infers many types):

  function square(n) {
    return n * n; // Error!
  }
  
  square("2");
  

• With TypeScript there's a migration effort and only some vanilla js static analysis without it:
  • noImplicitReturns which prevents you from forgetting to return at the end of a function.
  • noFallthroughCasesInSwitch что полезно, если вы никогда не хотите забывать оператор break между регистрами в блоке switch.
  • TypeScript также будет предупреждать о недоступном коде и метках, которые вы можете отключить с помощью allowUnreachableCode и allowUnusedLabels соответственно.

Больше преимуществ для Flow

Типы комментариев и Подавление ошибок продвинуть поддержку vanilla js на шаг вперед, позволяя постепенно включать проверки типов с помощью юридических комментариев js, которые аннотируют тип или подавляют определенные проверки, которые вы может быть еще не готов. Типы комментариев были запросом функции в TypeScript в течение некоторого времени и только недавно за это был пиар (см. предыдущую ссылку).

Недостатки потока

Тем не менее, вся простота Flow достигается за счет довольно сложной сложной конфигурации с некоторыми раздражающие предостережения, например, как он проверяет типы сторонних библиотек и т. д. Лучший совет кому-то могут рассказать о Flow: попробуйте сделать перекрестные ссылки на все, что вы читаете в их документации, так как она устарела и в некоторых случаях может вводить в заблуждение.