React Interceptorを理解する

こんにちは、Habr！



信じられないほどの誇りと安心を持って、私たちは今夜、 Reactに関する新しい本を印刷所に手渡しました。







この機会に、ダン・アブラモフによる記事のわずかに要約された翻訳を提供します。 私たち自身がすでに楽しみにしている本については、第5章で説明しています。



先週、 Sophie Alpertと私はReact Conf会議で「インターセプター」の概念を紹介し、続いてRyan Florenceからのトピックの詳細な議論を行いました 。



インターセプターの助けを借りて解決しようとしている問題の範囲を理解するために、この全体講義をご覧になることを強くお勧めします。 しかし、私はあなたの時間を非常に高く評価しているため、この記事ではインターセプターに関する主な考慮事項を簡単に説明することにしました。

注：Reactインターセプターはまだ実験段階です。 今それらを掘り下げる必要はありません。 また、この出版物は私の個人的な見解を示していることに注意してください。これはReact開発者の立場と一致しないかもしれません。

インターセプターが必要な理由



コンポーネントの編成とダウンストリームのデータフローは、大きなUIを小さく独立した再利用可能なフラグメントの形式で編成するのに役立つことが知られています。 ただし、ロジックは状態を保持し、関数または他のコンポーネントに抽出できないため、特定の制限を超える複雑なコンポーネントを分割することはできません 。 Reactが「職務分離」を達成できないと言う人は、これについて不満を言うことがあります。

このようなケースは非常に一般的であり、たとえば、アニメーション、フォーム処理、外部データソースへの接続、およびコンポーネントで実行する必要のある他の多くの操作に関連付けられています。 コンポーネントだけの助けを借りてこのような問題を解決しようとすると、通常、

• リファクタリングとテストが難しい巨大なコンポーネント 。
• さまざまなコンポーネントとライフサイクルメソッド間のロジックの複製 。
• 複雑なパターン 、特に、小道具や高次コンポーネントのレンダリング。

これらすべての問題を解決するには、インターセプターが最も有望であると考えています。 インターセプターは、コンポーネント内のロジックを再利用可能な分離ユニットの形式で整理するのに役立ちます 。











インターセプターは、R​​eactの哲学（明示的なデータフローと構成）に沿っており、コンポーネント間だけでなく、コンポーネント内にあります 。 それがインターセプターがReactコンポーネントモデルに自然に適合するように思える理由です。



レンダリングプロパティや高次コンポーネントなどのパターンとは異なり、スニファーは不必要に深い添付ファイルでコンポーネントツリーに負担をかけません。 また、不純物に固有の欠点もありません。



一見インターセプターがワープしたとしても（最初は私と同じように！）このオプションにチャンスを与えて実験することをお勧めします。 気に入っていただけると思います。



Reactはインターセプターによる膨張ですか？



インターセプターの詳細を説明するまでは、Reactでインターセプターを追加することはエンティティの単なる乗算であると心配するかもしれません。 これは公正な批判です。 私はこれを考えます：短期的には、あなたは（それらを研究するために）余分な認知的負荷を本当に感じますが、最終的には気分が良くなるだけです。



インターセプターがReactコミュニティーに根付いた場合、実際には、Reactアプリケーションを作成するときに管理する必要のあるエンティティの数が減ります。 インターセプターを使用すると、関数、クラス、高次コンポーネント、コンポーネントレンダリングを切り替えるのではなく、常に関数を使用できます。



実装サイズの増加に関しては、インターセプターをサポートするReactアプリケーションは約1.5kB（分+ gzip）だけ増加します。 これ自体はそれほど多くはありませんが 、インターセプターコードは通常、クラスを使用する同等のコードよりも適切に縮小されるため、インターセプターを使用すると、アセンブリのサイズが小さくなる可能性が非常に高くなります。 次の例は少し極端ですが、すべてがそうである理由を明確に示しています （ クリックしてスレッド全体を展開します）。







インターセプターの提案に革命的な変更はありません 。 新しいコンポーネントでインターセプターを使用し始めても、コードは正常に機能します。 実際、これはまさに私たちが推奨するものです。グローバルに何も書き換えないでください！ すべての重要なコードでインターセプターの使用が確立されるまで待つのが賢明でしょう。 それでも、アルファバージョン16.7を試して、 インターセプターの提案についてのフィードバックを残し、バグを報告していただければ幸いです。



インターセプターとは何ですか？



インターセプターが何であるかを理解するには、一歩戻って、コードの再利用とは何かを考える必要があります。



現在、Reactアプリケーションでロジックを再利用する方法は数多くあります。 したがって、何かを計算するために、単純な関数を作成してから呼び出すことができます。 また、コンポーネント（それ自体が関数またはクラスになります）を作成することもできます。 コンポーネントはより強力ですが、それらを使用する場合、UIを表示する必要があります。 したがって、コンポーネントを使用すると、非ビジュアルロジックを送信するのに不便です。 そのため、レンダリングプロパティや高次コンポーネントなどの複雑なパターンになります。 Reactは、コードを再利用する一般的な方法が1つしかなくてもそれほど簡単ではないのではないでしょうか？



関数は再利用可能なコードに最適のようです。 関数間でロジックを渡すことは最も安価です。 ただし、Reactのローカル状態は関数内に保存できません。 コードを再構築したり、Observablesなどの抽象化を導入したりせずに、コンポーネントコンポーネントから「ウィンドウサイズの追跡と状態の更新」や「値のアニメーション化」などの動作を抽出することはできません。 どちらのアプローチもコードを複雑にするだけであり、Reactはそのシンプルさで私たちにとって素晴らしいものです。



インターセプターはまさにこの問題を解決します。 インターセプターのおかげで、関数からReact機能（たとえば、状態）を使用できます（1回だけ呼び出すことで）。 Reactは、Reactブリックに対応するいくつかの組み込みインターセプターを提供します：状態、ライフサイクル、およびコンテキスト。



インターセプターは通常のJavaScript関数であるため、Reactで提供される組み込みインターセプターを組み合わせて「ネイティブインターセプター」を作成できます 。 したがって、複雑な問題は1行のコードで解決でき、アプリケーションでそれを掛けたり、Reactコミュニティで共有したりできます。



注意：厳密に言えば、独自のインターセプターはReactの機能には含まれません。 独自のインターセプターを作成する機能は、当然、非常に内部的な組織に由来します。



コードを見せてください！



コンポーネントを現在のウィンドウ幅にサブスクライブしたいとします（たとえば、他のコンテンツを表示したり、表示領域を狭くしたりするため）。

今日、同様のコードをいくつかの方法で書くことができます。 たとえば、クラスを作成するには、いくつかのライフサイクルメソッドを作成します。または、プロパティのレンダリングに頼ったり、再利用を希望する場合は高次のコンポーネントを適用したりすることもできます。 ただし、これに匹敵するものはないと思います。







gist.github.com/gaearon/cb5add26336003ed8c0004c4ba820eae



このコードを読んだ場合、それはまさにそれが言うことをすることを意味します 。 コンポーネント内のウィンドウの幅を使用し、Reactはコンポーネントが変更された場合にコンポーネントを再描画します。 これはインターセプターがまさに必要なものです-状態や副作用が含まれている場合でも、コンポーネントを本当に宣言的にするために。



この独自のインターセプターを実装する方法を検討してください。 ローカルのReact状態を使用して現在のウィンドウの幅を維持し、副作用を使用してウィンドウのサイズを変更するときの状態を設定できます。







gist.github.com/gaearon/cb5add26336003ed8c0004c4ba820eae



上記のように、 useState



やuseEffect



などのReactの組み込みインターセプターはuseState



として機能します。 コンポーネントから直接使用することも、 useWindowWidth



などの独自のインターセプターをアセンブルすることもできます。 独自のインターセプターを使用することは、組み込みのReact APIを操作することと同じように慣用的です。



このレビューで組み込みインターセプターの詳細をお読みください。



インターセプターはカプセル化されます-インターセプターが呼び出されるたびに、現在実行中のコンポーネント内の分離されたローカル状態を受け取ります。 この特定の例では、これは重要ではありません（ウィンドウの幅はすべてのコンポーネントで同じです！）。しかし、これがインターセプターの威力にかかっています。 これらは、状態ではなく、状態を保持するロジックを分離することを目的としています。 ダウンストリームデータストリームを中断したくありません！



各インターセプターには、ローカル状態と副作用が含まれる場合があります。 関数間で通常行われているように、複数のインターセプター間でデータを転送できます。 JavaScript関数であるため、引数を取り値を返すことができます。



以下は、インターセプターを試すReactアニメーションライブラリの例です 。

表示されているソースコードで見事なアニメーションが実装されていることに注目してください。同じレンダリング関数内の複数のネイティブインターセプター間で値を渡します。







codesandbox.io/s/ppxnl191zx



（この例については、 このガイドで詳しく説明します 。）



インターセプター間でデータを転送できるため、アニメーションの実装、データのサブスクライブ、フォームの管理、その他のステートフルな抽象化の操作に非常に便利です。 インターセプターの場合、レンダリングプロパティや高次コンポーネントとは異なり、レンダーツリーに「偽の階層」はありません 。 これらは、コンポーネントにアタッチされた「メモリセル」の2次元リストに似ています。 余分なレベルはありません。



クラスはどうですか？



私たちの意見では、私たち自身のインターセプターは、オファー全体の中で最も興味深い詳細です。 ただし、独自のインターセプターが機能するためには、Reactは関数のレベルで状態と副作用を宣言する機能を提供する必要があります。 これにより、 useState



やuseEffect



などのuseState



インターセプターを実行できます。 詳細については、 ドキュメントを参照してください 。



このような組み込みインターセプターは、独自のインターセプターを作成するときだけでなく、便利であることがわかります。 また、必要な機能（状態など）を提供するため、コンポーネント全体を決定するのに十分です。 これが、インターセプターが将来Reactコンポーネントを定義するための主要な手段になることを望む理由です。

いいえ、段階的にクラスを廃止する予定はありません。 私たちはFacebookで何万ものクラスコンポーネントを使用していますが、私たちは（あなたと同じように）絶対に書き換えたくありません。 しかし、Reactコミュニティーがインターセプターの使用を開始した場合、コンポーネントを作成する2つの推奨される方法を保持することは不適切になります。 インターセプターは、クラスが使用されるすべての実用的なケースをカバーしますが、コードの抽出、テスト、および再利用の際の柔軟性を高めます。 それが、インターセプターをReactの将来についてのアイデアと結び付ける理由です。



インターセプターが魔法の場合はどうなりますか？



おそらくインターセプターのルールはあなたを困惑させるでしょう。



より高いレベルでインターセプターを呼び出すことは一般的ではありませんが、可能であれば、自分で条件内の条件を判別したくないでしょう 。 たとえば、教室では条件に拘束される条件を決定することはできません。また、Reactユーザーとの4年間のコミュニケーションについて、これに関する苦情は聞いていません。



このような設計は、過剰な構文ノイズを導入したり落とし穴を作成したりすることなく、独自のインターセプターを導入するために重要です。 私たちは習慣からそれが難しいことを理解していますが、それが提供する機会を考えると、この妥協は許容できると信じています。 同意しない場合は、自分で実験して、このアプローチが好きな方法を試してみることをお勧めします。



新しいルールがプログラマーを混乱させるかどうかを確認するために、私たちは今月、生産フックを使用しています。 練習によれば、人は数時間でインターセプターを習得します。 私は一見これらのルールは異端であるように思えましたが、この感覚はすぐに過ぎ去りました。 それが、Reactに初めて会ったときの印象でした。 （Reactが好きではありませんでしたか？そして、私は2度目だけが好きでした。）



注意：インターセプターの実装レベルでも魔法はありません。 Jamieによると 、彼女は次のようになります。







gist.github.com/gaearon/62866046e396f4de9b4827eae861ff19



インターセプターの展開リストを維持し、インターセプターを使用するたびにリスト内の次のコンポーネントに移動します。 インターセプターのルールのおかげで、それらの順序はどのレンダリングエンジンでも同じであるため、呼び出しごとにコンポーネントに正しい状態を提供できます。



（ Rudy Yardleyのこの記事では、すべてが写真で美しく説明されています！）



おそらく、Reactがインターセプターの状態をどこに保存するのか疑問に思っているかもしれません。 クラスの状態はどこにありますか。 Reactには、コンポーネントの定義方法に関係なく、各状態の最終的な真実を含む内部更新キューがあります。



インターセプターは、最近のJavaScriptライブラリーで非常に一般的なプロキシーおよびゲッターから独立しています。 したがって、インターセプターのマジックは、このような問題を解決する他の一般的なアプローチよりも少ないと言えます。 array.push



とarray.pop



の場合にarray.pop



（この場合、呼び出しの順序も重要です！）



インターセプターの設計は、Reactに関連付けられていません。 実際、提案の公開から数日後、さまざまな人々が、Vue、Webコンポーネント、さらには通常のJavaScript関数に対しても同じインターセプターAPIの実験的な実装を見せてくれました。

最後に、関数型プログラミングに夢中になっていて、Reactが実装の詳細として可変状態に依存し始めると不快になります。 ただし、インターセプター処理を純粋な形式で実装し、代数的効果（JavaScriptでサポートされている場合）に限定できることは安心できます。 当然のことながら、システム内レベルでは、Reactは常に可変状態に依存していました。これはまさに避けたいことです。



どちらの視点があなたに近いか（実用的または独断的）に関係なく、これらのオプションの少なくとも1つがあなたにとって理にかなっていることを願っています。 最も重要なこととして、私の意見では、インターセプターは作業を簡素化し、ユーザーにとって作業がより便利になります。 それがインターセプターが私にそのような賄briを送ることです。