web-dev-qa-db-fra.com

Réagissez - en utilisant TypeScript vs Flow vs?

J'apprends actuellement à réagir et je pense que je le comprends assez bien. Cependant, quelque chose me préoccupe dans le développement d’applications React robustes: quels outils les développeurs utilisent-ils pour la vérification de type statique?

J'aime beaucoup TypeScript. Je pense que cela réduit considérablement les difficultés liées au développement d'applications JavaScript, grâce à la vérification de type et à d'autres fonctionnalités intéressantes. Visual Studio Code offre également une finition vraiment agréable. Et je sais que je peux le faire fonctionner avec React en utilisant typings + DenifitelyTyped .

Le fait est qu'il n'y a pas beaucoup de tutoriels sur l'utilisation de React + TypeScript. De plus, il ne semble pas y avoir beaucoup d'articles sur le développement de ce combo. D'autre part, beaucoup de gens semblent utiliser Flow , qui est un projet soutenu par Facebook (et je suppose qu'ils l'utilisent également).

J'ai réussi à trouver un discussion sur Reddit avec les avantages et les inconvénients d'aller de la manière React + TypeScript/React + Flow. Cependant, à mon avis, il semble être assez désuet, car il a environ 10 mois maintenant. Je pense que beaucoup de choses ont changé depuis.

J'ai également trouvé deux articles sur l'utilisation de React + Flow et React + TypeScript . L'auteur évoque certains problèmes rencontrés lors de l'utilisation des deux options et conclut que TypeScript est "le meilleur choix à l'heure actuelle" (novembre 2015), notamment parce que le projet Flow présente de nombreux problèmes et que l'activité des développeurs est faible sur Facebook. Il mentionne également que cela ne fonctionne pas bien avec Babel?

Donc, je suppose que la question serait: est-il prudent d’utiliser le combo React + TypeScript ou vais-je rencontrer des difficultés? Qu'en est-il de Flow? Existe-t-il d'autres outils similaires que je devrais consulter? Quelle approche recommanderiez-vous?

Mise à jour septembre 2017:

Ayant plus de un an d'expérience dans l'utilisation quotidienne de TypeScript et jouant avec Flow pendant un certain temps, j'ai tiré les conclusions suivantes:

  • TypeScript est toujours difficile à utiliser à ce jour. Le problème est que le monde JavaScript bouge tellement vite que TypeScript continue de prendre du retard. Vous envisagez d'utiliser cette nouvelle fonctionnalité de l'étape 3 de l'ES7? Non, vous ne pouvez pas. Vous souhaitez obtenir des conseils de type pour la dernière version de certaines bibliothèques? Attends un mois ou deux, peut-être plus ...
  • Le flux a parcouru un long chemin, il a été beaucoup amélioré, il peut attraper des choses que TS ne peut pas. Mieux encore, cela fonctionne enfin sous Windows. En outre, il existe un excellent plugin pour VS Code (aucune idée pourquoi il n’a que 3/5 de classement). Et cela fonctionne à 100% avec React Native, TypeScript n’y étant même pas encore à 50%.
  • La plupart du temps, vous n'avez pas du tout besoin de types. Toute la saisie supplémentaire en vaut rarement la peine. JS est un langage typé dynamiquement, surmontez-le :)

TL; DR: Si vous envisagez d'utiliser un vérificateur de type, je vous recommande d'utiliser Flow.

javascriptreactjstypescriptbabeljsflowtype
41
Honza Kalfus

Je vais commencer cette réponse en disant que je n’ai jamais utilisé Flow, je ne peux donc pas en dire beaucoup à ce sujet. Mais nous utilisons React et TypeScript au travail et cela fonctionne très bien.

Nous bénéficions de tous les avantages que vous connaissez déjà, tels que le refactoring, la sécurité des types, la complétion automatique, etc.

Bien sûr, d'après ce que j'ai vu, la syntaxe Flow est plus propre que TypeScript, mais vous pouvez ajouter vos types à l'aide de TypeScript de manière incrémentielle. Je pense que c'est plus une question de goût. Certaines personnes préfèrent que le code soit explicitement saisi, d’autres préfèrent taper moins et avoir une inférence plus forte. 

À propos des technologies, je dirais que TypeScript est une valeur sûre, Microsoft pousse le langage ( il y aura bientôt une version 2 ), Angular l’utilise aussi et il y a beaucoup de développeurs Angular. Même ici, sur SO, la balise TypeScript a plus de 4 000 adeptes et il est rare d’avoir une question sans réponse.

Le gros problème avec TypeScript, du moins pour nous, est que de temps en temps, nous décidons d’utiliser un composant ou une bibliothèque qui n’a pas les définitions de types, nous devons donc les créer nous-mêmes. Mais je suppose que c'est un moyen de contribuer à la communauté.

18
thitemple

Je me suis posé la même question (mais pas avec React) et j'ai trouvé les articles suivants utiles pour évaluer les deux:

L'approche adoptée par les concepteurs de flux se sent plus fonctionnelle avec une meilleure inférence de type et une meilleure approche pour les valeurs nulles. Cependant, TypeScript prend mieux en charge la communauté, en particulier en ce qui concerne la saisie de types pour les bibliothèques tierces via http://definitelytyped.org/ , ce qui est important pour que les types passent dans tout votre code pour une sécurité maximale. TypeScript est créé par Microsoft, qui possède une riche histoire en matière d'écriture de compilateurs et d'évolution de la technologie dans des directions favorables. Il convient de noter que C # et le fait qu'ils ajoutent déjà des types non nuls (2016-07-11): https://blogs.msdn.Microsoft.com/TypeScript/2016/07/11/announcing-TypeScript-2-0-beta/

TypeScript semble être le pari le plus sûr aujourd'hui.

Et pour ceux qui essaient de saisir TypeScript dans une base de code existante, j’ai trouvé les paramètres suivants dans mon fichier tsconfig.json très utiles pour permettre à TypeScript de bien coexister avec JavaScript (permettant la transition d’un fichier à la fois):

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

Dans mon développement de React, j'ai un complexe Babel / Webpack / Flow / Moka configuration de la chaîne d'outils et je n'ai jamais eu de problèmes avec Flow. Cela prend des efforts pour tout configurer (Webpack peut être décourageant au début), mais ensuite, ça fonctionne. Le flux est définitivement la voie à suivre car il s’agit d’une technologie plus étroite et plus ciblée, et donc plus susceptible de bien fonctionner avec d’autres outils. En revanche, TypeScript tente d’être bien plus qu’un simple outil de vérification de type inférence/statique, il apporte donc un bagage et des hypothèses supplémentaires. Donc, React est un outil spécialisé qui fait une chose, tandis que TypeScript est en réalité un langage superposé à JavaScript. Pour que Microsoft comprenne bien, les fichiers TypeScript ont aussi généralement une extension différente (.ts au lieu de .js), car vous utilisez maintenant un autre langage.

TypeScript utilise la génération de code pour cracher du code JavaScript alors que dans Flow, les annotations sont simplement supprimées, il n'y a pas de génération de code en tant que telle. Auparavant, les gens de Microsoft faisant la promotion de TypeScript utilisaient pour déclarer que la génération de code était "fichier local" (je ne me souviens pas de la terminologie exacte utilisée). Cela était censé fournir une assurance apaisante que le compilateur TypeScript ne fait rien de trop magique. En tout cas, je ne trouve plus cette déclaration bien en évidence. Avec Flow, vous n'avez pas besoin de telles assurances car vous écrivez en JavaScript simple (ou quelle que soit la version d'ECMA pour laquelle vous avez configuré Babel) et les annotations sont, comme je l'ai dit, tout simplement supprimées.

Sans oublier que TypeScript provient d'une société spécialisée dans des pratiques techniques contraires à l'éthique et discutable (je n'exclue pas que TypeScript puisse éventuellement devenir la mère de tous les stratagèmes Embrace-Extend-Extinguish). N'oublions pas que Microsoft a fait tout ce qui était en son pouvoir pour que Javascript échoue comme ils (à juste titre, si tardivement) prévoyaient quelle menace il représentait et représente encore pour leur système d'exploitation pourri et leur suite bureautique.

De plus, le système de types de Flow était beaucoup beaucoup plus puissant la dernière fois que j'ai eu la peine d'évaluer TypeScript (vers 2015) et il était beaucoup plus facile de l'appliquer de manière incrémentielle ou même sporadique dans les sources. Pour l’intégration de bibliothèques tierces, j’utilise flowtyped et il est très rare que j’ai besoin de compléter celles-ci avec mes propres définitions.

Enfin, le fait que Angular utilise TypeScript ne signifie absolument rien, car Angular n’est pas vraiment pertinent pour les nouveaux projets. React a gagné haut la main, il est temps de passer à autre chose.

1
Marcus Junius Brutus