フロントエンドの世界での依存関係の反転。 ヤンデックス講義

依存性反転（DI）パターンは古くから知られていますが、フロントエンドの世界ではまだ広く使用されていません。 このレポートは、JS機能により、DIコンテナに基づいた堅牢なアーキテクチャを構築する方法の質問に答えます。 レポートの作成者は、Yandex.Collectionsのインターフェイス開発グループの責任者であるEugene ftdebugger Shpilevskyです。





-私の知る限り、70年代に発明された依存関係の反転、DIコンテナー、その他のパタ​​ーンは、フロントエンド開発の世界にあまりきちんと入っていませんでした。 これにはおそらく理由があります。 事実の一部は、多くの人々がなぜ彼らが必要なのか全く理解していないということです。





DIとは何か、依存関係の逆転とは何か、それがプロジェクトでどのように役立つか、そしてDIを使い始めるとどんな素晴らしいボーナスが得られるかを説明しようと思います。



手始めに、最も基本的な概念。 依存関係の逆転とは何ですか？ 機能を設計するとき、特定の個別のクラスが1つの機能を実行するだけの小さな状態に分解する必要があります。



スライドの例には、UserとUserSettingsがあります。 ユーザー設定に関連するすべてが別のクラスに移動されました。 これをどのように行うことができますか？ 2つのアプローチがあります。そのようなクラスのインスタンスを内部で作成するか、外部で受け入れるかです。 これが依存関係の反転の主な原則です。 外部からいくつかのインスタンスを作成してから内部に転送すると、いくつかの利点が得られます。









実際、理由は1つだけです。特定の実装に依存するのではなく、インターフェイスのみに依存するようになりました。 いくつかの小さな分解された関数が別のクラスで取り出されると言うとき、それがどのように実装されたかは重要ではありません。 使用することができ、インターフェイスが一致する場合、どのクラスのどのインスタンスがスリップされるかは関係ありません。 また、JSにはインターフェースがないため、このメソッドはより大きなインターフェースからも呼び出されます。





UserSettingsの例は少し文脈から外れており、毎日書くコードではありません。



JSの現実と現実に近い、もう少し一般的なコードは同期的です。 データモデルを作成する場合は、このデータをどこかから取得する必要があります。 最も一般的な方法の1つは、Ajaxを介してサーバーにアクセスし、データを同期的に受信して作成することです。



依存関係の反転のスタイルでこのコードを書き始めると、次のようになります。 このコードは最適な方法で書かれていないだけでなく、非常に怪しいものです。 ユーザーの写真を一覧表示するコンポーネントを1つだけ欲しかったので、このために大量のコードを書く必要がありました。



実際のプロジェクトでは、コンポーネント数は数十になり、ページ上でさえそのようなアセンブリは非常に怪物のようになります。







何ができますか？ コードを悪化させます。 最初のDIコンテナー、最も原始的な額を作成できます。 以前に書いたものをすべて取り込んで、メソッドにパックします。 ハッシュに入れます。これをDIと呼び、これをDIコンテナーと見なします。 その後、私たちは未来を少し良くするための第一歩を踏み出します。



一番下の行は、ユーザー、設定、写真、またはここで説明できる他の何百もの方法が必要なときはいつでも、DIを使用してそれを呼び出すことができます。設計されました。



モデル、クラス、コンポーネントの構築を担当するすべてのコードは、1つのコンテナーに分離されます。 当然、この方法でコードを記述することは困難であり、このファイルはすぐに大きくなります。 すでに問題があります。 コードを少し学ぶと、少なくともユーザーが2回ロードしていることに気付くでしょう。 これは悪いことです。これは避けなければなりません。



さらに、すべてのコードは定型文です。 いくつかの機能を使用して置き換えることができます。 そして、すべての問題を解決する独自のコンテナを作成できます。それはクールで高速です。 あなたが欲しいもの。



それが私が彼に望んだことです。





彼は自分でクラスを探す必要があります。 どこかからインポートし、作成して使用する必要があります。 これは望ましくありません。コンテナに任せてください。



彼にインスタンスを非同期に作成してほしい。 最初にコンテナにこのような要件を設定した場合、将来インスタンスを作成する方法、Ajaxに行くか、時間を費やすかどうか、または同期して行くかどうかに問題はありません。 作成が非同期の場合、すべてがすでに提供されています。



再利用。 これは非常に重要です。 大きなコンテナの作成を開始し、その中にインスタンスを再利用しない場合、多くの不要な不要なリクエストがサーバーに送られる危険があります。 これを避けたい。



最後のポイント。 前のスライドで示した必須の通常のコードは、誰も喜ばなかったと確信しています。 代わりに、このすべてが記述され、すべてが私のために機能する、通常の宣言的なJSONを書きたいです。





各問題の解決方法を段階的に学習します。



クラスを動的に見つけることをどのように教えることができますか？ webpackを使用できます。動的インポート機能があります。 このようなコードは、少し奇妙に思えますが、Webpackをバンドルした後でも機能します。 さらに、これらの条件に該当するすべてのクラスは、自動的に個別のバンドルになり、非同期でロードを開始します。 そして、クラス読み込みコードはすべてこのようになります。 クラスを同期的に要求して取得するだけです。 getClass関数は、希望どおりに表示される場合があります。 いくつかの依存関係を静的にロードする場合は、ここに記述できます。 よりスマートなバンドルが必要な場合は、こちらで説明できます。 これはすべて、概してあなた次第です。





インスタンスを作成するには2つの方法があります。 これがどのように起こるかという恐ろしい構成を思いつくか、ある種の慣習を導入することができます。 コーディングの必要はなく、何かを覚えて、常にこれらの標準に従うだけでよいので、私はコンベンションのやり方が好きです。



この場合、次の規則を導入します。すべてのクラスに静的ファクトリメソッドが必要です。 彼は、このクラスがどのように構築されるか、どの依存関係がスローされるかについて責任を負います。 彼はすべてに責任があります。



CreateInstanceは非常にシンプルであることが判明し、ファクトリは同期と非同期の両方になります。 さて、ユーザーを作成するためのコードは異なっていますが、それでもstillいです。





インスタンスを再利用します。 これを達成するために、新しいコンセプトを導入します。 DIコンテナの一部として作成されたインスタンスには、識別子が割り当てられます。 これらの識別子を考え出します。これらの識別子は、システムの一部のエンティティを記述します。 この場合、最後の行で現在のユーザーを説明します。 以前に作成した関数のクラスを何らかの方法で取得し、そのクラスからインスタンスを作成してキャッシュに入れます。



この例では、いくつかのバグが許可されています。 CreateInstanceキャッシュベースのメソッドの完全な実装には、約100行かかります。 気にする人は、 それを読むことができます 。





最後は依存関係です。 通常のハッシュについて説明します。キーはDIコンテナーからの識別子であり、値は上記のすべてを作成できる構成です。 UserSettingsクラスを取得して作成します。 currentUserでは、ユーザークラスを取得し、UserSettingsで依存関係としてポップします。 UserSettingsとは何ですか？ 以前に発表したもの。



このような構造を説明したので、形成された依存関係でツリー全体を通過する単純なアルゴリズムを開発できます。 実際、このツリーにはグラフが形成されています。 このようなアルゴリズムは、必要なものをすべて収集します。



スライドのノイズの量を減らすために、別の規則を紹介します。





なぜJSONで書くのではなく、何でも書いてください。そしてもっと単純な形式ですべてを記述してはどうでしょうか。 クラスが必要な場合-クラスと依存関係が必要な場合は文字列を取得します-配列を使用します。 どの形式を選択してもかまいません。 主なことは、それを楽しんで、ここで何が起こっているかを理解することです。 これは同じスライドで、書き直されただけです。





その結果、これらすべてを実装し、まとめると、自動バンドルが行われます。 ここで、現在のユーザーをリクエストすると、DIコンテナーがこのクラスを含むバンドルを同時にロードし、非同期に必要な依存関係を既にロードできるという興味深いオプションが得られます。 事実、彼はクラスの場所（おそらくある種のバンドル）と、必要な依存関係の種類に関する情報を持っているということです。 着陸の例：写真のリストを表示するコンポーネントを作成したい場合、写真でこれらのコンポーネントを描画するコードが存在するJSがまだロードされているので、その時点でデータのサーバーへのリクエストを送信できます。 それらの両方が最終的に満たされると、それを取得します。



これは、DIコンテナーを使用するだけで取得できます。他に何も必要ありません。 依存関係の配信が容易です。 DIコンテナーを最大限に使用し始めると、すべての一般的なユーティリティ、コンポーネント、データモデルなど、世界のすべてがそこに表示され始めます。 また、ある時点で何かを取得する必要がある場合は、1行の依存関係を記述するだけでよく、その作成方法、構成方法を気にせず、すべての段階を経る必要がある複雑なプロセス全体を説明します。 依存関係としてコンテナから取得するだけです。



コードの再利用。 特定のクラスで他のクラスのインスタンスを明示的に作成しないような方法で書き始めると、実装に縛られなくなります。 任意の種類のインスタンスを依存関係としてクラスにスリップできます。 写真の同じコンポーネントのフレームワーク内で、あらゆる種類の写真をロードして、どこからでも手のひらを引くことができます。 コンテナ内では、これらはすべて構成内の1行だけが異なります。 あなたはただ別の中毒を取ります、それはそれです、それはあなたにとって非常に簡単です。





コンテナがプロジェクトの非常に重要な場所に固定されるとすぐに、すべての基盤として使用し始めます。 DIコンテナを使用して通常のマルチページSPAを作成する方法を示したいと思います。



ある種のルーターを使用します。 その実装は重要ではありません。 何らかのURLでキャッチされたときに、このページに名前を付けることが重要です。 この場合、おそらく家とプロファイル。



コンテナを持ち帰り、そこにキーを家とプロファイルとして記述します。 私たちはそこに行きたくないすべてを説明します。 そして、何らかの種類のコンポーネントを取得して、ボディに挿入します。 この場合、これはある種のレイアウトです。 レイアウトはあちこちで使用され、異なる依存関係がそこに含まれています。 次に何をする？ どのコンポーネントがより深くなるか、すでにこの段階では重要ではありません。既に何らかの形で機能しているため、誰かがそれらをセットアップします。 私たちが今取り組んでいる抽象化のレベルだけが重要です。



それだけです。キーごと、ページ名ごとにDIコンテナに依存関係をリクエストできます。 この場合、これはレイアウト上のサインであり、このレイアウトには必要なすべてのデータ、すべてのコンポーネント、実行したいすべてが既に含まれています。 本体に追加するためだけに残ります。





これらすべてのテスト容易性はどうですか？ 使用を開始するとすぐに、クラスがコンテナに直接依存しないという状況が発生します。 あなたはどこにもいませんし、そのような依存関係が必要だという意味でコンテナを直接使用することは決してありません。それを取得して取得します。 いいえ、むしろ、前のスライドで示したように、アプリケーションのブートストラップのアーキテクチャの最下部にあります。



実際、クラスはまったく依存しておらず、どこからでもどこからでも移植できます。



すべての依存関係は作成中に渡され、テストについて話している場合は、この場所でmokee、フィクスチャデータなどを簡単に添付できます。 DIコンテナにより、すべてがそのように機能するような方法でコードを記述できました。





いくつかの例。 作成するとき、テストに携わっており、ユーザー設定を濡らして、書いたものではなく、私たちが望んでいることを正確に実行したい場合、ユーザーを作成し、テストデータをスリップすることができます。 このためにコンテナを使用できます-依存関係ツリーがすでに形成されているので、それらのいくつかを再定義できます。 将来的には、単にDIを操作するロジックによって、UserSettingsを取得したいと思ったすべての人が、どこにいてもそれらを受け取ることになります。 テストに使用できます。





別の興味深い例があります。 データを得るためにサーバーのどこかに行くすべてのデータモデルがこの目的のために書かれたajaxAdapterを使用すると仮定した場合、テスト中にロジックを実装できる独自のクラスTestAjaxAdapterに置き換えることができます。 これは、たとえばシノンで誰かがそれを濡らそうとした場合に実装される方法です。





または、さらに深くすることもできます。 このアダプターにこのロジックを実装したため、テストで最初に使用されたときに実サーバーからの要求と応答の記録が開始され、再起動するとキャッシュから単純に再現されました。 このキャッシュをテストデータのリポジトリに追加します。 そして、フィクスチャーでテストを行いたい場合、サーバーとの通信のロジックが既に実装されているためにフィクスチャーが時間とともに変化することを恐れている場合、TestAjaxAdapterを置き換えます。 リポジトリ内にキャッシュが形成され、その後再利用されます。





これをどのようにさらに興味深いものに使用できますか？ Geminiのテストについては、すでにここで言及されています。 これは視覚的な回帰テストの一種です。 誰も知らない、ジェミニは、完成したページでブロックのスクリーンショットを撮り、リポジトリのテストデータに入れて、逆テストを行いたいときに再起動し、スクリーンショットをピクセルごとに比較するテスト方法です。 どこかでピクセルが一致しなかった場合、テストは失敗しました。 これは非常にシンプルで効果的なタイプのテストであり、視覚的な回帰をチェックします。 私たちはCSSを使用していますが、次の機能を備えています。 ジェミニはこれらの故障を取り除くのに役立ちます。



この場所で何をしましたか？ すべてがDIコンテナを介して実装されているため、DIコンテナからの識別子をパラメータとして渡すことができるサーバーを特別に準備しました。 彼は単にそれを作成し、私たちが望んでいたこのコンポーネントだけをページに描いた。 この場合、レシピ、何らかのカード、テストが実行された実際のデータ、実際のスクリーンショットに関連するものがあります。



テストの実行後、ajaxAdaptersが置き換えられ、サーバーの通信方法に関連するキャッシュが形成されました。 このデータがあります-時間の経過とともに絶えず再現され、テストは安定します。



このアプローチは、すべてのタイプのテストに適用されます。 Seleniumブラウザコンポーネントにクリックしてクリックするだけでログインしたい場合、何も心配する必要はありません。コミットしたい機能が完全に機能するためです。 さらに、複数のブロックを同時に作成し、それらをページに表示してクリックすることもできます。 ブロック間には、何らかのイベント接続などがあります。 ブロックがこのサイトと一致しない場合でも、この方法でいくつかのロジックをテストできます。



DIとは何かについての簡単なレポートを読みました。 誰かが興味を持っていることを願っています。 詳細が必要な場合は、 メール 、 GitHub 、 電報 、 Twitterのリンクからアクセスできます。



ここにあるものに関する新しい情報を見つけることができるリンクがあります。 たとえば、私が話した完全に実装されたDIコンテナである逆変換DIコンテナは、TypeScriptにとって非常にクールなものです。 すべてをまとめる方法を理解するためのリンクがいくつかあります。

• github.com/ftdebugger/di.js
• dev.to/kayis/dynamic-imports-with-webpack-2
• www.npmjs.com/package/inversify
• github.com/vlyahovich/quantum-router

ありがとう