Reagieren – mit TypeScript vs. Flow vs.?

Ich lerne gerade React und ich glaube, ich verstehe es ziemlich gut. Es gibt jedoch eine Sache, die mich bei der Entwicklung robuster React-Anwendungen stört – welche Tools verwenden Entwickler für die Überprüfung statischer Typen?

Ich mag TypeScript sehr. Ich denke, es reduziert den Aufwand bei der Entwicklung von JavaScript-Anwendungen dank der Typprüfung und anderer netter Funktionen erheblich. Visual Studio Code bietet auch eine wirklich schöne Codevervollständigung. Und ich weiß, dass ich es mit React zum Laufen bringen kann, indem ich es verwende Eingaben + Eindeutig Typisiert.

Die Sache ist, dass es nicht viele Tutorials zur Verwendung von React + TypeScript gibt. Es scheint auch nicht viele Artikel über die Entwicklung mit dieser Kombination zu geben. Auf der anderen Seite scheinen viele Leute zu konsumieren Fließenein Projekt, das von Facebook unterstützt wird (und ich denke, sie nutzen es auch).

Ich habe es geschafft, eine zu finden Diskussion auf Reddit mit Vor- und Nachteilen über den Weg von React + TypeScript / React + Flow. Allerdings scheint es mir ziemlich veraltet zu sein, da es jetzt ungefähr 10 Monate alt ist. Ich denke, seitdem hat sich viel verändert.

Ich habe auch zwei Artikel über die Verwendung gefunden Reagieren + Fließen und Reagieren + TypeScript. Der Autor gibt einige Probleme an, auf die er bei der Verwendung beider Optionen gestoßen ist, und kommt zu dem Schluss, dass TypeScript „derzeit die beste Wahl“ ist (November 2015), insbesondere weil das Flow-Projekt viele Probleme hat und eine geringe Entwickleraktivität von Facebook erhält. Er erwähnt auch, dass es nicht gut mit Babel zusammenpasst?

Ich denke, die Frage wäre also: Ist es sicher, die React + TypeScript-Kombination zu verwenden, oder werde ich auf einige Schwierigkeiten stoßen? Was ist mit Flow? Gibt es noch andere ähnliche Tools, die ich ausprobieren sollte? Welche Vorgehensweise würden Sie empfehlen?

Aktualisierung September 2017:

Nachdem ich mehr als ein Jahr Erfahrung mit der täglichen Verwendung von TypeScript habe und eine Weile mit Flow herumgespielt habe, bin ich zu folgenden Schlussfolgerungen gekommen:

• Die Verwendung von TypeScript ist bis heute mühsam. Das Problem ist, dass sich die JavaScript-Welt einfach so schnell bewegt, dass TypeScript immer hinterherhinkt. Denken Sie darüber nach, diese schicke neue ES7-Stufe-3-Funktion zu verwenden? Nein, das kannst du nicht. Möchten Sie Typhinweise für die neueste Version einer Bibliothek erhalten? Warte einen Monat, oder zwei, vielleicht länger…
• Flow hat einen langen Weg zurückgelegt, es wurde stark verbessert, es kann einige Dinge erfassen, die TS nicht kann. Das Beste ist, dass es endlich unter Windows funktioniert. Außerdem gibt es ein großartiges Plugin für VS Code (keine Ahnung, warum es nur eine Bewertung von 3/5 hat). Und es funktioniert zu 100 % mit React Native, TypeScript ist noch nicht einmal zu 50 % da.
• Meistens braucht man überhaupt keine Typen. All das zusätzliche Tippen lohnt sich selten. JS ist eine dynamisch typisierte Sprache, komm darüber hinweg 🙂

TL;DR: Wenn Sie vorhaben, einen Typprüfer zu verwenden, empfehle ich die Verwendung von Flow.

Update Februar 2019:

Ich glaube, die obige Empfehlung ist veraltet und nicht mehr relevant. Drei Gründe:

• Haken reagieren sind hier. Sie machen die Typprüfung Ihres Codes viel einfacher. In den meisten Situationen ist kein zusätzlicher Code erforderlich.
• Die Typinferenz von TypeScript wurde verbessert.
• TypeScript hat eine viel größere Community als Flow. Sogar Garn, der Paketmanager von Facebook, bewegt sich weg von Flow zu TypeScript.

Daher denke ich, dass TypeScript im Jahr 2019 eine viel pragmatischere Wahl ist als Flow.

Ob es sich überhaupt lohnt, einen Typprüfer zu verwenden, hängt meiner Meinung nach von der Projektgröße ab. Kleine Projekte brauchen es wahrscheinlich nicht.

Ich werde diese Antwort damit beginnen, dass ich Flow noch nie verwendet habe, daher kann ich nicht viel darüber sagen. Aber wir verwenden React und TypeScript bei der Arbeit und es funktioniert großartig.

Wir haben alle Vorteile, von denen Sie meiner Meinung nach bereits wissen, wie Refactoring, Typsicherheit, Autovervollständigung usw.

Sicher, für das, was ich gesehen habe, ist die Flow-Syntax sauberer als TypeScript, aber Sie können Ihre Typen mithilfe von TypeScript inkrementell hinzufügen. Ich denke, das ist eher Geschmackssache. Einige Leute ziehen es vor, den Code explizit einzugeben, andere bevorzugen es, weniger einzugeben und eine stärkere Typinferenz zu haben.

Was die Technologien betrifft, würde ich sagen, dass TypeScript eine sichere Sache ist, Microsoft treibt die Sprache voran (Es wird bald eine Version 2 geben), Angular verwendet es ebenfalls und es gibt viele Angular-Entwickler. Selbst hier auf SO hat das Tag TypeScript mehr als 4.000 Follower und es kommt selten vor, dass eine Frage unbeantwortet bleibt.

Das große Problem mit TypeScript, zumindest für uns, ist, dass wir uns von Zeit zu Zeit entscheiden, eine Komponente oder eine Bibliothek zu verwenden, die nicht über die Typdefinitionen verfügt, sodass wir sie selbst erstellen müssen. Aber ich denke, das ist eine Möglichkeit, etwas zur Gemeinschaft beizutragen.

Ich habe mir gerade dieselbe Frage gestellt (allerdings nicht mit React) und fand die folgenden Artikel nützlich, um die beiden zu bewerten:

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

Der von den Flow-Designern gewählte Ansatz fühlt sich funktionaler an, mit einer besseren Typinferenz und einem besseren Ansatz für Nullen. TypeScript hat jedoch eine bessere Community-Unterstützung, insbesondere in Bezug auf das Einziehen von Typen für Bibliotheken von Drittanbietern über http://definitelytyped.org/ Dies ist wichtig, damit Typen für maximale Typsicherheit durch Ihren gesamten Code fließen. TypeScript wird von Microsoft entwickelt, das eine lange Geschichte beim Schreiben von Compilern und der Weiterentwicklung der Technologie in günstige Richtungen hat – bemerkenswert ist hier C # und die Tatsache, dass sie bereits Nicht-Null-Typen hinzufügen (2016-07-11): https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

TypeScript scheint heute die sicherere Wahl zu sein.

Und für diejenigen, die TypeScript in einer vorhandenen Codebasis ausprobieren, fand ich die folgenden Einstellungen in meiner tsconfig.json-Datei sehr hilfreich, damit TypeScript gut mit JavaScript koexistieren kann (wobei der Übergang jeweils nur eine Datei ermöglicht wird):

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

In meiner React-Entwicklung habe ich einen ziemlichen Komplex Babel / Webpaket / Fließen / Mokka Toolchain eingerichtet und hatte nie Probleme mit Flow. Es erfordert einige Mühe, alles einzurichten (Webpack kann anfangs entmutigend sein), aber danach funktioniert es einfach. Flow ist definitiv der richtige Weg, da es sich um eine engere und fokussiertere Technologie handelt, die sich eher gut mit anderen Tools kombinieren lässt. Im Gegensatz dazu versucht TypeScript, viel mehr zu sein als nur ein Tool zur Typinferenz / statischen Typprüfung, und bringt daher zusätzlichen Ballast und Annahmen mit sich. React ist also ein spezialisiertes Tool, das eine Sache gut macht, während TypeScript praktisch eine Sprache ist, die auf JavaScript aufgesetzt ist. Um sicherzustellen, dass Microsoft seinen Standpunkt deutlich macht, haben TypeScript-Dateien normalerweise auch eine andere Erweiterung (.ts Anstatt von .js), weil Sie jetzt eine andere Sprache verwenden, verstanden?

TypeScript verwendet die Codegenerierung, um JavaScript auszuspucken, während in Flow die Anmerkungen einfach entfernt werden, es gibt keine Codegenerierung als solche. In der Vergangenheit haben die Microsoft-Leute, die TypeScript befürworteten, eine Aussage darüber gemacht, dass die Codegenerierung “dateilokal” ist (ich erinnere mich nicht an die genaue verwendete Terminologie). Dies sollte eine beruhigende Gewissheit geben, dass der TypeScript-Compiler nichts zu Magisches tut. Jedenfalls finde ich diese Aussage nicht mehr prominent dargestellt. Mit Flow brauchen Sie solche Zusicherungen nicht, da Sie in einfachem JavaScript schreiben (oder für welche ECMA-Version Sie Babel konfiguriert haben) und die Anmerkungen werden, wie gesagt, einfach entfernt.

Ganz zu schweigen davon, dass TypeScript von einem Unternehmen stammt, das sich auf unethische und fragwürdige technische Praktiken spezialisiert hat (ich schließe nicht aus, dass sich TypeScript letztendlich als die Mutter aller Embrace-Extend-Extinguish-Tricks herausstellen könnte). Vergessen wir nicht, dass Microsoft haben alles in ihrer Macht stehende getan, um Javascript zum Scheitern zu bringen da sie (zu Recht, wenn auch verspätet) voraussahen, welche Bedrohung es für ihr beschissenes Betriebssystem und ihre aufgeblähte Office-Suite darstellte und immer noch darstellt.

Außerdem war das Typsystem von Flow viel Das letzte Mal, als ich mich die Mühe gemacht habe, TypeScript zu evaluieren (ca. 2015), war es viel leistungsfähiger, und es war viel einfacher, es schrittweise oder sogar sporadisch in den Quellen anzuwenden. Für die Integration von Bibliotheken von Drittanbietern verwende ich flusstypisiert und es ist sehr selten, dass ich die dort gefundenen mit meinen eigenen Definitionen ergänzen muss.

Schließlich bedeutet die Tatsache, dass Angular TypeScript verwendet, absolut nichts, da Angular für neue Projekte nicht wirklich relevant ist. React hat zweifellos gewonnen, Zeit, weiterzumachen.