JavaScriptでの型安全性：フローとTypeScript

流血の企業でUI開発を扱っている人なら誰でも、おそらく「MicrosoftのTypeScript」を意味する「型付きJavaScript」について聞いたことがあるでしょう。しかし、このソリューションの他に、少なくとも1つの一般的なJSタイピングシステムがあり、ITの世界の主要なプレーヤーからのものもあります。これはFacebookからのフローです。マイクロソフトが個人的に嫌いなため、以前は常にフローを使用していました。客観的には、これは既存のユーティリティとの良好な統合と移行の容易さによって説明されました。



残念ながら、2021年には、人気とさまざまなユーティリティ（およびライブラリ）からのサポートの両方で、フローがTypeScriptよりも大幅に劣っていることを認めなければなりません。それを棚に埋めて、サボテンを噛むのを やめる時が来ました 。事実上のTypeScript標準に移動します。しかし、この下で、最後にこれらのテクノロジーを比較したいと思います。たとえば、Facebookからのフローのカップル（またはカップルではない）です。

JavaScriptで型安全性が必要なのはなぜですか？

JavaScriptは素晴らしい言語です。いいえ、これは好きではありません。 JavaScriptを中心に構築されたエコシステムは素晴らしいです。 2021年、彼女は言語の最新機能を使用できるという事実を本当に賞賛し、ビルドシステムの1つの設定を変更することで、IE8を含む古いバージョンのブラウザーでの実行をサポートするために実行可能ファイルをトランスパイルします。 、夜は覚えていません。 「HTMLで書く」（JSXを意味する）ことができ、ユーティリティbabel



（または tsc



）を使用して、 すべてのタグを、Reactライブラリ（または他の、ただし別の投稿で詳しく説明します）を呼び出すなどの正しいJavaScript構造に置き換えます。



JavaScriptがブラウザで実行されるスクリプト言語として優れているのはなぜですか？

• JavaScriptを「コンパイル」する必要はありません。 JavaScript構造を追加するだけで、ブラウザーはそれらを理解する必要があります。これはすぐに便利でほとんど無料のものをたくさん与えます。たとえば、ブラウザで直接デバッグすることは、プログラマー（たとえば、コンパイラーのデバッグオプションと対応するライブラリの束を含めることを忘れてはなりません）の責任ではなく、ブラウザーの開発者の責任です。 10k行のプロジェクトがコンパイルされている間、10〜30分（C / C ++の場合はリアルタイム）待つ必要はありません。行を変更し、ブラウザページをリロードして、コードの新しい動作を観察するだけです。また、たとえばwebpackを使用している場合は、ページも再読み込みされます。多くのブラウザでは、devtoolsを使用してページ内でコードを変更できます。
• - . 2021 . Chrome/Firefox, , , 5% (enterprise-) 30% (UI/) , .
• JavaScript , . — ( worker'). , 100% CPU ( UI ), , , Promise/async/await/etc.
• 同時に、なぜJavaScriptが重要なのかという質問すら考えていません。結局のところ、JSの助けを借りて、次のことができます：フォームを検証し、ページコンテンツを完全にリロードせずに更新し、非標準の動作効果を追加し、オーディオとビデオを操作し、エンタープライズアプリケーションのクライアント全体をJavaScript。

ほとんどすべてのスクリプト（インタプリタ）言語と同様に、JavaScriptでは...壊れたコードを書くことができます。ブラウザがこのコードに到達しない場合、エラーメッセージ、警告、または何も表示されません。一方では、これは良いことです。大規模で大規模なWebサイトがある場合、ボタンクリックハンドラーのコードに構文エラーがあっても、ユーザーがサイトを完全にロードしないことはありません。



しかし、もちろん、これは悪いことです。サイトのどこかで何かが機能していないという事実自体が悪いからです。そして、コードが動作するサイトに到達する前に、サイト上のすべてのスクリプトをチェックして、少なくともコンパイルされていることを確認するのは素晴らしいことです。そして理想的には-そして働く。このために、さまざまなユーティリティのセットが使用されます（私のお気に入りのセットは、npm + webpack + babel / tsc + karma + jsdom + mocha + chaiです）。



私たちが理想的な世界に住んでいる場合、サイト上のすべてのスクリプトは、1行のスクリプトであっても、テストでカバーされます。しかし、残念ながら、世界は理想的ではなく、テストでカバーされていないコードのすべての部分について、私たちはある種の自動化された検証ツールにしか頼ることができません。確認できるもの：

• JavaScript. , JavaScript, , , . /// .
• . , , . , :
  
  
  
  

  var x = null;
  x.foo();
  
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
      

  
  
  . — null .

セマンティクスエラーに加えて、さらにひどいエラー、つまり論理エラーが発生する可能性があります。プログラムがエラーなしで実行されたが、結果がまったく期待されたものではない場合。文字列と数字が追加されたクラシック：

console.log( input.value ) // 1
console.log( input.value + 1 ) // 11

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

既存の静的コード分析ツール（eslintなど）は、プログラマーがコードで行う潜在的なエラーのかなりの数を追跡しようとする可能性があります。例えば：

• 誤ったループ終了条件で無限forループを禁止する
• Promiseコンストラクターへの引数としての非同期関数の禁止
• 条件での割り当ての禁止
• そして他の人

これらのルールはすべて、本質的にリンターがプログラマーに課す制約であることに注意してください。つまり、リンターは実際 にはJavaScript言語の機能を低下させるため、プログラマーは潜在的なミスを減らすことができます。 all-allルールを有効にすると、条件で割り当てを行うことは不可能になり（JavaScriptは最初はこれを許可しますが）、オブジェクトリテラルで重複キーを使用し、呼び出すことさえできません console.log()



。



変数の型の追加と呼び出しの型チェックは、潜在的なエラーを減らすためのJavaScript言語の追加の制限です。





数値に文字列を掛けようとしています





オブジェクトの存在しない（型に記述されていない）プロパティにアクセスしようとしました。





引数の型が一致しない関数を呼び出そうとしました。



型チェッカーなしでこのコードを記述した 場合、コードは正常にトランスパイルされます。オブジェクトのタイプに関する情報を（明示的または暗黙的に）使用しない場合、静的コード分析の手段はこれらのエラーを見つけることができません。



つまり、JavaScriptに入力を追加すると、プログラマーが作成するコードに追加の制限が追加されますが、スクリプトの実行中に（つまり、ユーザーのブラウザーで）発生する可能性のあるエラーを見つけることができます。

JavaScriptタイピング機能

JavaScriptタイプをサポートするための両方のエンジンは、ほぼ同じ機能を備えています。ただし、強い型の言語を使用している場合、型付きのJavaScriptでもJavaとは非常に重要な違いがあります。すべての型は基本的にインターフェイス、つまりプロパティのリスト（およびその型や引数）を記述します。また、2つのインターフェイスが同じ（または互換性のある）プロパティを記述している場合は、それらを互いに代わりに使用できます。つまり、次のコードは型付きJavaScriptでは正しいですが、JavaやC ++では明らかに正しくありません。

type MyTypeA = { foo: string; bar: number; }
type MyTypeB = { foo: string; }

function myFunction( arg : MyTypeB ) : string {
    return `Hello, ${arg.foo}!`;
}

const myVar : MyTypeA = { foo: "World", bar: 42 } as MyTypeA;
console.log( myFunction( myVar ) ); // "Hello, World!"

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

MyTypeBインターフェイスにはfoo



型を 持つプロパティが必要string



ですが、MyTypeAインターフェイスを持つ変数には必要なので、このコードは型付きJavaScriptの観点からは正しい です。



このコードは、変数のリテラルインターフェイスを使用して、少し短く書き直すことができ ます myVar



。

type MyTypeB = { foo: string; }

function myFunction( arg : MyTypeB ) : string {
    return `Hello, ${arg.foo}!`;
}

const myVar = { foo: "World", bar: 42 };
console.log( myFunction( myVar ) ); // "Hello, World!"

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

myVar



この例の変数タイプ はリテラルインターフェイス { foo: string, bar: number }



です。それでもarg



関数の 引数の期待されるインターフェースと互換性があるmyFunction



ので、このコードは、たとえばTypeScriptの観点からエラーがありません 。



この動作により、さまざまなライブラリ、カスタムコードを操作するとき、さらには関数を呼び出すときの問題の数が大幅に減少します。典型的な例は、いくつかのライブラリが有効なオプションを定義し、それらをオプションオブジェクトとして渡す場合です。

// -  
interface OptionsType {
    optionA?: string;
    optionB?: number;
}
export function libFunction( arg: number, options = {} as OptionsType) { /*...*/ }

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

//   
import {libFunction} from "lib";
libFunction( 42, { optionA: "someValue" } );

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

タイプはOptionsType



ライブラリからエクスポートされないことに注意してください （カスタムコードにインポートされることもありません）。ただし、これにより、options



関数の2番目の引数、および型指定システムにリテラルインターフェイスを使用して関数を呼び出し、 この引数の型の互換性を確認することができます。Javaでこのようなことをしようとすると、コンパイラ間で明らかに混乱が生じます。

ブラウザの観点からはどのように機能しますか？

MicrosoftのTypeScriptもFacebookのフローもブラウザでサポートされていません。また、最新のJavaScript言語拡張機能は、一部のブラウザーでまだサポートされていません。では、このコードは、まず、正確性をどのようにチェックし、次に、ブラウザーによってどのように実行されるのでしょうか。



答えはtraspilingです。すべての「非標準」JavaScriptコードは、「非標準」（ブラウザーには不明）コードをブラウザーが理解できる一連の命令に変換する一連のユーティリティを通過します。そして、タイピングの場合、「変換」全体は、すべての型の改良、すべてのインターフェース記述、コードからのすべての制限が単に削除されるという事実にあります。たとえば、上記の例のコードは...になります。

/* : type MyTypeA = { foo: string; bar: number; } */
/* : type MyTypeB = { foo: string; } */

function myFunction( arg /* : : MyTypeB */ ) /* : : string */ {
    return `Hello, ${arg.foo}!`;
}

const myVar /* : : MyTypeA */ = { foo: "World", bar: 42 } /* : as MyTypeA */;
console.log( myFunction( myVar ) ); // "Hello, World!"

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

それら。

function myFunction( arg ) {
    return `Hello, ${arg.foo}!`;
}
const myVar = { foo: "World", bar: 42 };
console.log( myFunction( myVar ) ); // "Hello, World!"

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この変換は通常、次のいずれかの方法で行われます。

• フローからタイプ情報を削除するには、babelプラグインを使用します：@ babel / plugin-transform-flow-strip-types
• 2つのソリューションのいずれかを使用してTypeScriptを操作できます。まず、babelと@ babel / plugin-transform-typescriptプラグインを使用できます
• 次に、babelの代わりに、tscと呼ばれるMicrosoft独自のトランスパイラーを使用できます。このユーティリティは、 babelではなくアプリケーションビルドプロセスに組み込まれています。

フローおよびTypeScript（tscを使用）のプロジェクト設定の例。



バベル+ストリップとtscのアプローチの違いは、組み立ての点ではわずかです。最初のケースでは、babelが使用され、2番目のケースでは、tscになります。





ただし、eslintなどのユーティリティを使用する場合は違いがあります。eslintでリントするためのTypeScriptには、さらに多くのバグを見つけることができる独自のプラグインのセットがあります。ただし、リンターによる分析時に、変数のタイプに関する情報が含まれている必要があります。これを行うには、コードパーサーとしてtscのみを使用し、babelは使用しないでください。しかし、リンターにtscを使用する場合、構築にbabelを使用するのは誤りです（使用するユーティリティの動物園は最小限に抑える必要があります！）。

ライブラリのタイプ

ライブラリがnpmリポジトリに公開されると、公開されるのはJavaScriptバージョンです。プロジェクトで使用するために、公開されたコードを変更する必要はないと想定されています。つまり、コードはすでにbabelまたはtscを介して必要なtraspilationを通過しています。しかし、コード内のタイプに関する情報はすでに失われています。何をすべきか？



フローでは、「純粋な」JavaScriptバージョンに加えて、ライブラリに拡張子が付いたファイルが含まれると想定されています。 .js.flow



すべてのタイプ定義を含むソースフローコードが含まれています。次に、フローを分析するときに、これらのファイルを接続して型チェックを行うことができます。プロジェクトのビルドとその実行時には、これらのファイルは無視されます。通常のJSファイルが使用されます。簡単なコピーで.flowファイルをライブラリに追加できます。ただし、これにより、npmでのライブラリのサイズが大幅に増加します。



TypeScriptでは、ソースファイルを並べて保持することはお勧めしませんが、定義のリストのみを保持することをお勧めします。ファイルがある場合 myModule.js



、プロジェクトを分析するときに、TypeScriptは近くのファイルを探します。このファイルには myModule.js.d.ts



、すべてのタイプ、関数、およびタイプの分析に必要なその他のものの定義（コードではありません！）が表示されます。tscトランスパイラーは、ソースTypeScriptからそのようなファイルを独自に作成できます（オプションを参照） declaration



ドキュメント内）。

レガシーライブラリのタイプ

フローとTypeScriptの両方で、最初にこれらの説明が含まれていないライブラリの型宣言を追加する方法があります。しかし、それはさまざまな方法で行われます。



フローについては、Facebook自体がサポートする「ネイティブ」な方法はありません。しかし、そのような定義をリポジトリに収集するフロー型のプロジェクト があります。実際、npmがそのような定義をバージョン管理するための並列方法であり、更新の非常に便利な「集中型」方法でもありません。



TypeScriptでは、このような定義を記述する標準的な方法は、「@ types」プレフィックスが付いた特別なnpmパッケージでそれらを公開すること です。..。ライブラリのタイプの説明をプロジェクトに追加するには、対応する@ types-libraryを接続するだけで十分です。たとえば、 @types/react



Reactや @types/chai



chaiなどです。

フローとTypeScriptの比較

フローとTypeScriptを比較する試み。選択された事実は、NathanSebhastianの記事「TypeScriptVSFlow」から収集され、一部は独立して収集されます。



さまざまなフレームワークにわたるネイティブサポート。ネイティブ-はんだごてとサードパーティのライブラリおよびプラグインを使用した追加のアプローチはありません。



様々な支配者



これらの数字を見ると、私にはフローの使用を推奨する道徳的権利がありません。しかし、なぜ私はそれを自分で使用したのですか？以前はフローランタイムなどがあったからです。

フローランタイム

flow-runtimeは、フロータイプをランタイムに埋め込み、実行時に変数タイプを定義するために使用できる、そして最も重要なこととして、実行時に変数のタイプをチェックできるようにする、babelのプラグインのセットです。これにより、実行時に、たとえば自動テストや手動テスト中に、アプリケーションの追加のバグをキャッチできます。



つまり、実行時に（もちろん、デバッグアセンブリで）、アプリケーションは、すべてのタイプの変数、引数、サードパーティ関数の呼び出しの結果、およびすべて、すべて、すべてを明示的にチェックして、それらのタイプに準拠しているかどうかを確認しました。



残念ながら、2021年の新年には、リポジトリの作成者が 情報を追加しました彼はもはやこのプロジェクトの開発に関与しておらず、通常はTypeScriptに切り替えています。実際、流れを維持する最後の理由は私にとって非推奨になりました。さて、TypeScriptへようこそ。