TypeScriptをより厳密にします。Yandexレポート

TypeScriptを、厄介なバグから保護し、コードへの信頼を高める、厳格で公正なコンパニオンにする方法はありますか？アレクセイベセロフスキー veselovskiyai許されない自由に目をつぶるTS構成のいくつかの機能を検討しました。レポートでは、避けるのが最善のことと、細心の注意を払う必要のあることについて概説しています。すばらしいio-tsライブラリについて学習します。これにより、完全に記述された場所でエラーを引き起こす可能性のあるコードへのデータ入力を簡単に検出し、防止することもできます。



-みなさん、こんにちは。私の名前はLeshaです。フロントエンド開発者です。はじめましょう。私自身と私が取り組んでいるプロジェクトについて少しお話します。FlowはYandex.Practicumから英語を学んでいます。リリースは今年4月に行われました。フロントはTypeScriptで直接記述されていましたが、それ以前はコードはありませんでした。







私の経験について少し。遠い年に、私はプログラミングを始めました。 2013年に彼は働き始めました。







すぐに私は前線にもっと興味があることに気づきましたが、静的に型付けされた言語の経験がありました。 JavaScriptを使い始めましたが、この静的型付けはありませんでした。便利そうに見えて、気に入りました。



プロジェクトの変更で、TypeScriptを使用して作業するようになりました。 TypeScriptに切り替えることで実現した長所について説明します。プロジェクトを理解しやすくなります。プロジェクトで使用されるデータタイプとそれらの間の変換について説明します。







コードを変更する方が安全です。バックエンドまたはコードの一部に変更があった場合、TypeScriptはエラーが発生した場所を強調表示します。



タイプについての懸念は少なくなります。新しい機能を作成するときは、機能が機能するタイプをすぐに設定するので、異なるデータを受け取る心配が少なくなります。



nullまたはundefinedが発生する恐れはありません。パラノイアである必要はなく、不要なifおよび同様の構造を挿入する必要はありません。







今年の初めに、私はフローに移動しました。TypeScriptもここで使用されていますが、私はそれを少し認識していませんでした。どうして？彼は私に親切すぎました。クライアントエラーの4分の1は、nullと未定義に関連していました。私は何が問題なのかを理解し始め、TypeScriptのすべての動作を変更する構成の1行を見つけました







。これはstrictの包含です。そこにはありませんでしたが、検証を改善するためにオンにする必要がありました。

TypeScript：厳密

厳格とは何ですか？それは何で構成されていますか？







これは個別にオンにできるフラグのセットですが、私の意見では、それらはすべて非常に便利です。 noImplicitAny-このフラグを有効にする前に、たとえば、anyなどのパラメータが暗黙的になる関数を宣言できます。このフラグを有効にする場合、TypeScriptがコンテキストからタイプを計算できない場所にタイピングを追加する必要があります。



つまり、2番目のケースでは、コンテキスト自体がないため、入力を追加する必要があります。マップがある3番目のケースでは、数値タイプがあることがコンテキストから明らかであるため、のタイプを追加することはできません。







noImplicitThis。 TypeScriptでは、コンテキストがない場合にこれを入力する必要があります。コンテキストがオブジェクトまたはクラスである場合、これを行う必要はありません。







alwaysStrict。すべてのファイルに「usestrict」を追加します。ただし、JavaScriptがコードを実行する方法には影響します。 （...）







strictBindCallApply。何らかの理由で、このオプションを有効にする前に、TypeScriptはバインド、適用、および型の呼び出しをチェックしません。それをオンにした後、彼はそれらをチェックし、私たちがそのような厄介なことをすることを許可しません。







strictNullChecksは、私の意見では、最も必要なチェックです。 nullまたはundefinedが発生する可能性のある場所を入力時に指定する必要があります。含める前に、明示的に指定されていない場合にnullまたはundefinedを渡すことができるため、エラーが発生します。その後、コントロールははるかに良くなります。







次に、strictFunctionTypes。ここでの状況はもう少し複雑です。 3つの機能があると想像してみましょう。 1つは動物、もう1つは犬、もう1つは猫を扱います。犬と猫は動物です。つまり、犬を猫と同じように扱うのは、犬が違うので間違っているということです。動物と同じように犬でも正しく動作します。



3番目のオプションは、犬のような動物を扱う場合です。何らかの理由で、最初はTypeScriptで許可されていますが、このオプションを有効にすると無効になり、特定のチェックが実行されます。







次に、strictPropertyInitialization。これはクラス用です。プロパティを宣言するとき、またはコンストラクターで初期値を設定する必要があります。このルールを回避する必要がある場合があります。感嘆符を使用することもできますが、繰り返しになりますが、これにはもう少し注意が必要です。



それで、strictを有効にする必要があることがわかりました。オンにしようとすると、多くのエラーが表示されます。そのため、厳密に移行構成を使用することにしました。 3つのステップで厳密に設定します。







最初の段階：tsconfigに「strict」：trueを追加します。したがって、開発環境では、strictが含まれているために発生するエラーのある場所の入力を求められます。



ただし、webpackの場合、strictがfalseになる特別なtsconfigを作成し、これをビルド時に使用します。つまり、アセンブリ中に何も壊れませんが、エディターではこれらのエラーが表示されます。そして、すぐに修正できます。次に、時々第2段階に移りますが、これは修正です。通常のtsconfigを使用してプロジェクトをビルドします。出てきた間違いのいくつかを修正し、自由な時間にこれをすべて繰り返します。



このようなアクションにより、これまでのところエラーの数を400から200に減らしました。第3段階に進むことを楽しみにしています。つまり、ビルド時にwebpackTsConfigを削除し、tsconfigを使用しますが、厳密に有効にします。

TypeScript:

strictでカバーされていないTypeScriptの小さな微妙な点について少し話すことができますが、正しく形式化するのは困難です。







感嘆符演算子から始めましょう。それはあなたに何をさせるのですか？この場合、未定義にできないかのように、未定義にできるフィールドを参照してください。厳密モードでは、フィールドにアクセスしようとすると、次のように明示的に言うのが理にかなっています。それは間違いなくnullまたは未定義ではないと確信しています。しかし、これは悪いことです。突然nullまたは未定義であることが判明した場合、実行時に自然にエラーが発生するためです。



ESLintは、そのようなことを回避するのに役立ちます。単に禁止するだけです。やりました。前の例を今すぐ修正するにはどうすればよいですか？



そのような状況にあるとしましょう。







要素があり、リンクまたはスパンタイプにすることができます。私たちの頭では、スパンはテキストのみであり、リンクはテキストとリンクであることがわかります。



（写真）



しかし、TypeScript言語を伝えるのを忘れたため、getItemHtml関数で、リンクの場合に次のように言わなければならない状況が発生します。hrefはオプションではなく、間違いなくそうなります。これは、エラーが発生する可能性のある場所でもあります。それを修正する方法は？







最初のオプションは、入力を修正することです。つまり、リンクにはhrefが必要であり、spanにはオプションであることをTypeScriptに明示的に示します。







そして、ここでは感嘆符は必要ありません。







2番目の修正オプション。アイテムタイプが私たちによって記述されておらず、私たちがそれを取得して制限することはできないと仮定します。次に、同様の方法で書き直すことができます。







注意：チェックが表示されたばかりです。次に、プログラマーがこのコードを作成するときにこの値を予期していなかったログが表示されるため、将来的にはこのエラーが表示され、適切なアクションが実行されます。



次に、どういうわけかアイテムをレンダリングしようとしています。ここでは、単にユーザーにエラーを与えることができます。ただし、これが重要でないデータである場合は、次のようなスタブを作成できます。

なので

さらに。as演算子もあります。それはあなたに何をさせるのですか？







それはあなたが言うことを可能にします-私はよく知っています、そのようなタイプがあります-そしてまたあなた自身を間違いに導きます。

配列

闘争の方法は同じです。もう少し注意する必要があるのは配列です。TypeScriptは万能薬ではなく、いくつかの点をチェックしません。たとえば、存在しない配列要素を参照できます。この場合、配列の最初の要素を取得し、このコードでエラーを取得します。どうすればこれを修正できますか？







繰り返しますが、2つの方法があります。最初の方法は入力です。私たちは最初の要素を持っていると言い、恐れることなくこの要素を参照します。または、何かが突然間違っているかどうか、空でない配列が明示的に予期されているかどうかを確認し、ログに記録します。

オブジェクト

オブジェクトについても同じです。任意の数のプロパティを持つことができ、未定義のエラーが発生する可能性のあるオブジェクトを宣言できます。







ここでも、必要なプロパティを明示的に指示するか、単に確認することができます。

どれか

今、明らかなことは何でもです。







入力がまったくなかったかのように、オブジェクトの任意のプロパティを参照できます。この場合、xを使用してやりたいことが何でもできます。そして再び足を撃ち、間違いを犯します。



繰り返しますが、ESLintではこれを明示的に禁止することをお勧めします。しかし、それが単独で現れる状況があります。







たとえば、この場合、JSON.parseはこのタイプanyだけを生成します。何ができるの？







あなたは簡単に言うことができます：私はあなたを信じていません、私はそれが何であるかを知らないと言ったほうがいいです、そして私はそれを続けます。それと一緒に暮らすには？これが架空の例です。







ユーザーがいて、そのユーザーには必須の名前とオプションの電子メールがあります。







parseUser関数を作成しています。 JSON文字列を受け取り、オブジェクトを返します。今、私たちはこれらすべてをチェックし始めます。最初に、前のスライドでよく知っている、解析済みで不明な行が表示されます。次に、チェックを開始します。







オブジェクトでないかnullの場合は、エラーをスローします。







さらに、必須のnameプロパティがない場合、または文字列でない場合は、エラーがスローされます。これがコードの続きです。







すべての必須フィールドがすでに収集されているため、ユーザーの形成を開始します。







次に、メールフィールドがあるかどうかを確認します。そうである場合は、そのタイプをチェックし、タイプが一致しない場合は、エラーをスローします。メールがない場合は何も送信せず、結果を返します。すべて順調。しかし、あなたは最も単純なタイプのためにたくさん書く必要があります。

そしてそれは多くのチェックが必要です

典型的なJSONリクエストは次のようになるため、多くの検証が必要です。







さらに面倒なことはありませんが、これは単にfetchとjson（）です。anyからSomeRequestResponseへの変換が代わりに表示されます。これも戦う必要があります。前の方法で行うことも、少し異なる方法で行うこともできます。

io-ts

内部的には同じです。型チェックには特別なライブラリを使用します。この場合、それはio-tsです。これは、それを操作する方法の簡単な例です。







前のユーザータイプを取得して、使用しているライブラリ内に記述してみましょう。はい、ここでは入力が少し複雑ですが、2つの条件を同時に満たす必要があります。必須の名前フィールドを持つオブジェクトと、オプションの電子メールフィールドを持つオブジェクトである必要があります。どうすればこれをすべて確認できますか？







同じparseUserを書いてみましょう。この場合、User.decodeメソッドを使用しています。すでにペアリングされているオブジェクトをそこに渡し、結果を返します。おそらく珍しい形式で。タイプEitherのオブジェクト。2つの状態になります。最初は正しいです。これは通常、すべてがうまくいったことを意味します。左はうまくいかなかったと言います。これらの状態の両方に、詳細を学習できるプロパティがあります。成功した場合、これは実行の結果であり、エラーの場合はエラーです。



結果が左の状態であるかどうかを確認します。もしそうなら、エラーが発生したと言います。さらに、すべてが順調であれば、単に結果を返します。

エラーの表示

エラーの表示について。あなたはそれを少し改善することができます。これにはio-ts-reportersを使用します。 io-tsと同じ作者が書いたライブラリです。これにより、エラーを美しく表示できます。彼女がすること？ここでアヒルがいる場所のコードを変更しました。結果を受け取り、文字列の配列を返します。 1行にまとめて表示するだけです。最終的に何が得られますか？







JSON文字列にnullを渡すとします。







2つのエラーが発生します。これは、交差を行ったため、実装の微妙さによるものです。エラーは十分に明らかです。どちらも、オブジェクトを期待していたがnullになったと言っています。これらの条件のそれぞれについて、個別にエラーが発生するだけです。







次に、そこに空の配列を渡してみましょう。同じになります。







彼は簡単に言うでしょう：私もオブジェクトを期待していましたが、空の配列を受け取りました。







そのため、誤ったデータの送信を開始するとどうなるかを引き続き確認します。たとえば、空のオブジェクトを渡します。







これで、必須の名前フィールドがないという事実について1つのエラーが発生します。彼は名前フィールドが文字列型であることを期待していましたが、最終的には未定義になりました。このエラーから何が起こったのかも理解しやすいです。







次に、そこに間違ったタイプを渡そうとします。前の例とほぼ同じエラーも発生します。







しかし、ここで彼は私たちが伝えた意味をはっきりと私たちに書いています。







io-tsは他に何ができますか？TypeScriptタイプを取得できます。つまり、この行を追加します。typeofとtypeofを追加するだけで、アプリケーションでさらに使用できるTypeScriptタイプを取得できます。便利です。







このライブラリは他に何ができますか？タイプを変換します。サーバーにリクエストを送信しているとしましょう。サーバーは、日付をunix時間形式で送信します。また、io-tsライブラリの作成者であるio-ts-typesからの特別なライブラリがあります。元々作成された変換と、それらの変換を簡単に作成できるようにするツールがあります。日付フィールドを追加します。これはサーバーから数値として取得され、最終的にはDateオブジェクトとして受信されます。

タイプを説明しましょう

このライブラリの内容を見て、最も単純なタイプを説明してみましょう。







まず、それが一般的にどのように記述されているかを見てみましょう。変換にも必要であることを考えると、同じように説明されますが、かなり複雑です。サーバーからクライアントへの相互作用、およびクライアントからサーバーへの逆変換を考慮すると、サーバーからクライアントへの変換は別として。



タスクを少し単純化しましょう。チェックするタイプを書くだけです。この場合、これらのフィールドの意味を理解しましょう。 name-タイプ名。







エラーを表示する必要があります。前の例で見たように、エラーはどういうわけかタイプの名前を綴っています。ここで指定できます。



次に、検証機能があります。たとえば、サーバーからは不明な値が必要です。エラーを正しく表示するためのコンテキストを取ります。そして、エラーまたは検証済みの値の2つの状態でEitherオブジェクトを返します。



さらに2つの機能があります：isとencode。それらは逆変換するために使用されますが、今は触れないでください。







最も単純な文字列タイプをどのように表すことができますか？名前をstringに設定し、それが文字列であることを確認します。直接変換する場合、これは必要ありませんが、正式に記述します。そして、typeofを実行してチェックします。成功した場合、結果は成功を返し、エラーの結果として失敗を返します。エラーが正しく表示されるように、コンテキストも追加されます。そして、逆変換がないので、同じものを返すだけです。

練習中

実際には何ですか？サーバーからのデータをチェックすることにしたのはなぜですか？







少なくとも、データベースにはJSONがあります。もちろん、私たちは彼がうまく運営され、いくつかの時点でチェックされると信じています。ただし、形式は少し変更される可能性があります。報復措置を講じるために、フロントエンドを壊したり、エラーをすぐに見つけたりしてはなりません。



明示的に入力せずにサーバー上にPythonがあります。これでも、小さな問題が発生することがあります。また、故障しないように、万が一の場合に備えて、簡単に確認し、さらに安全を確保することができます。



サーバーの応答に関する明確なドキュメントはありません。おそらく、サーバーは、彼が与えるものよりも、彼に来るものについてより心配しています。はい、これは私たちの問題です-壊れないでください。







何を見つけましたか？すでに少し使い始めています。サーバーが空の配列ではなく空のオブジェクトを提供することがわかりました。空のオブジェクトを返すように書かれたコードを調べました。



さらに-いくつかのフィールドがありません。それらは必須であると考えましたが、オプションであることが判明しました。



null可能なフィールドが単に欠落している場合がありました。つまり、オプションのフィールドは、単に渡さない場合とnullを渡す場合の2つの方法で表示できます。また、それは必ずしも正しく私たちに届いたわけではありません。コードの途中でエラーをキャッチしないようにするために、リクエスト時にこれをキャッチできます。







私たちは今何を持っていますか？サーバーからの多くの応答をすでに確認し、気に入らない場合はログに記録しました。次に、これを分析してタスクを設定します。フロントエンドでの入力を変更するか、バックエンドで編集します。ここでは、サーバーからのデータを変更しません。文字列の代わりにnullが送信された場合、たとえば、空の文字列に変更しません。



私たちの計画はチェックしてログに記録することですが、エラーがあれば修正してください。誤ったデータを受け取った場合は、この値を修正して、ユーザーがコード内に入る代わりに少なくとも何かを表示できるようにします。







小さな結果。TypeScriptがより多くのことを助け、as、any、および感嘆符を除外するように、strictをオンにします。TypeScriptの配列とオブジェクトにはさらに注意を払い、すべての外部データもチェックします。ちなみに、これらはサーバーだけではありません。また、イベントで受信されるメッセージであるlocalStorageを確認することもできます。たとえば、postMessage。



ご清聴ありがとうございました。