完全に再利用可能なJSXコンポーネントのDI

こんにちは、私の名前はSergeyです。Web上のコンポーネントを再利用する問題に興味があります。 彼らがどのように SOLIDを反応に適用しようとしているのかを見て、私はこのトピックを継続し、 依存性注入またはDIのアイデアを開発することでどのように良好な再利用が達成できるかを示すことにしました。

Webのフレームワークを構築するための基盤としてのDIは、かなり新しいアプローチです。 危機にwhatしているものを明確にするために、リアクション開発者向けの通常のことから始めます。

コンテキストからDIへ

Reactを操作するときに、多くの人がコンテキストを使用したと確信しています。 直接ではない場合、おそらくreduxで接続するか、mobx-reactで注入します。 一番下の行は、あるコンポーネント（MessageList）でコンテキストで何かを宣言し、別のコンポーネント（ボタン）でこの何かをコンテキストから外したいということです。

const PropTypes = require('prop-types'); const Button = ({children}, context) => <button style={{background: context.color}}> {children} </button>; Button.contextTypes = {color: PropTypes.string}; class MessageList extends React.Component { getChildContext() { return {color: "purple"}; } render() { return <Button>Ok</Button>; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すなわち 親コンポーネントに一度context.color



が設定されると、contextTypesを介して色への依存が宣言されているすべての基本コンポーネントに自動的に転送されます。 したがって、階層内のプロパティをスクロールせずにボタンをカスタマイズできます。 さらに、階層のどのレベルでも、 getChildContext() ...



、すべての子コンポーネントの色を再定義できます。

このアプローチにより、コンポーネントが相互に分離され、構成と再利用が簡素化されます。 上記の例では、親コンポーネントで色を定義するだけで十分で、すべてのボタンの色が変わります。 さらに、Buttonコンポーネントは別のライブラリにある場合があり、リファクタリングする必要はありません。

しかし、反応については、思慮深さが不十分であるため、このアプローチはまだ十分に開発されていません。 開発者は、直接使用することをお勧めしません。

これは実験的なAPIであり、Reactの将来のリリースで機能しなくなる可能性があります

ドキュメントに書かれています。 現在かなりの期間、現在の形で実験的であり、開発が停止したという感覚があります。 コンポーネントのコンテキストは、インフラストラクチャ（getChildContext）にリンクされており、PropTypesを介して疑似型付けされ、 アンチパターンを考慮するサービスロケーターに似ています 。 私の意見では、コンテキストの役割は過小評価されており、反応では二次的です： ローカリゼーションとテム化、および reduxやmobxなどのライブラリへのバインド。

他のフレームワークでは、同様のツールがより適切に開発されています。 たとえば、vue： provide / injectで、angularでは、その角度diはすでにtypescript型サポートを備えた本格的なファンシーDIです。 実際、2番目のバージョンのAngularから始めて、開発者はフロントエンドに関してバックエンドエクスペリエンス（DIが長い間存在していた場所）を再考しようとしました。 しかし、反応とそのクローンについて同様のアイデアを開発しようとすると、どのような問題が解決されますか？

打ち負かすか、それは質問です

本格的な反応/リデュースアプリケーションでは、すべてがリデュースアクションによって実行されるわけではありません。 重要でないチェックマークの状態は、setStateを使用して実装する方が便利です。 結局のところ、reduxを使用するのは面倒ですが、setStateを使用することは普遍的ではなく、単純です。 彼は常に手元にいます。 有名な著者による「Reduxを必要としないかもしれない」という記事は、「スケーリングする必要がない場合はreduxを使用しないでください」と言っており、この二重性を確認しています。 問題は、これは現在必要ではないことであり、明日はチェック状態のログ記録を固定する必要があるかもしれません。

同じ著者のPresentational and Container Componentsによる別の記事では、「すべてのコンポーネントは等しい（Presentational）が、一部はより等しい（Container）」と言われ、同時に花崗岩に刻まれています（redux、mobx、relay、setStateに釘付け）。 Containerコンポーネントのカスタマイズは複雑です。再利用することを目的としておらず、すでに状態の実装とコンテキストに合わせられています。

Container-componentsの作成を何らかの方法で単純化するために、それらはHOCを思い付きましたが、実際にはほとんど変更されていません。 彼らは単に、接続/注入を介して純粋なコンポーネントとredux、mobx、relayなどを組み合わせるようになりました。 そして、結果のモノリシックコンテナをコードで使用します。

言い換えれば、プレゼンテーションとコンテナを言いますが、再利用可能と再利用不可能を意味します。 最初はカスタマイズするのに便利です プロパティ内のすべての拡張ポイント、および2番目-リファクタリング。状態といくつかのロジックにネストされているため、プロパティが少ないためです。 これは、2つの相反する問題を解決するための一種の妥協です。その代償は、コンポーネントを2つのタイプに分離し、 オープン性/クローズ性の原則を犠牲にすることです。

たとえば、記事「 Replace and Conquer-the SOLID approach 」のように、ほとんどのコンポーネントを可能な限り単純にし、整合性を悪化させることが提案されています。 しかし、単純なものから複雑なコンポーネントをどこかで組み立てる必要があり、同時にそれらをカスタマイズする方法についての疑問が残ります。 すなわち 問題は別のレベルに持ち越されます。

 <ModalBackdrop onClick={() => this.setState({ dialogOpen: false })} /> <ModalDialog open={this.state.dialogOpen} > <ModalDialogBox> <ModalDialogHeaderBox> <ModalDialogCloseButton onClick={() => this.setState({ dialogOpen: false })} /> <ModalDialogHeader>Dialog header</ModalDialogHeader> </ModalDialogHeaderBox> <ModalDialogContent>Some content</ModalDialogContent> <ModalDialogButtonPanel> <Button onClick={() => this.setState({ dialogOpen: false })} key="cancel"> {resources.Navigator_ButtonClose} </Button> <Button disabled={!this.state.directoryDialogSelectedValue} onClick={this.onDirectoryDialogSelectButtonClick} key="ok"> {resources.Navigator_ButtonSelect} </Button> </ModalDialogButtonPanel> </ModalDialogBox> </ModalDialog> </ModalBackdrop>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それでもこれらの端末コンポーネントをカスタマイズしないことに同意する場合、実際には多数のボイラープレートコードを取得します。1つのButtonを置き換えるために、コンポーネント全体が再構築されます。 このアプローチでは、本格的なソリッドは不可能です。 変更せずに拡張できない状態へのコンポーネントバインダーと、内部のロジックのないコンポーネントコンポーネントは常に存在し、これは使用が困難です。

試作機

依存性注入のアイデアを開発すると、これらの問題のいくつかを解決できます。 この例に基づいてソリューションを分析しましょう。

 // @flow // @jsx lom_h // setup... class HelloService { @mem name = '' } function HelloView(props: {greet: string}, service: HelloService) { return <div> {props.greet}, {service.name} <br/><input value={service.name} onChange={(e) => { service.name = e.target.value }} /> </div> } // HelloView.deps = [HelloService] ReactDOM.render(<HelloView greet="Hello"/>, document.getElementById('mount'))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィドル

関数の状態には、状態で機能するかどうかに関係なく、1つの汎用コンポーネント形式があります。 コンテキストは型を使用します。 babel-plugin-transform-metadataを使用して、依存関係の説明が自動的に生成されます。 ただし、これを行うタイプスクリプトに似ていますが、クラスに対してのみです。 引数は手動で記述できますが、 HelloView.deps = [HelloService]

ライフサイクル

しかし、コンポーネントのライフサイクルはどうでしょうか。 そして、その中に低レベルのコードを扱うことが本当に必要なのでしょうか？ HOCを通じて、例えばrelay / graphqlのように、これらのライフサイクルメソッドをメインコードから削除しようとしています。

データの更新はコンポーネントの責任ではないという考え方です。 このデータにアクセスした後にデータをダウンロードする場合（たとえば、 mobx-utilsのlazyObservableを使用する場合）、この場合componentDidMountは必要ありません。 jqueryプラグイン、つまり、要素のrefsプロパティなどをねじ込む必要がある場合

ベンダーロックイン試薬のない汎用コンポーネントが現在存在しているとします。 別のライブラリに割り当てたとしましょう。 コンテキストに入ってくるものを拡張およびカスタマイズする方法を決定することは残っています。 結局のところ、HelloServiceは特定のデフォルトの実装です。

そこに行く-どこにあるかわからない、持っていく-何がわからない

要件の頻繁な変更のために、コンポーネントがカプセル化の干渉を開始するアプリケーションの一部である場合はどうなりますか。 もちろんそれ自体ではありませんが、今日のほぼすべてのフレームワークで実装されている形式（テンプレート、関数の構成、またはJSXの形式）です。

コンポーネントの場合、そのコンポーネント用に何をカスタマイズするかを事前に言うことはできません。 そして、読みやすさを損なうことなく、最初の実装を複雑にし、最初から再利用に投資しないで、リファクタリングせずにコンポーネントの内部部分を変更する方法が必要です（オープン性/クローズ性の原理）（すべてを予測することはできません）。

たとえば、DIなしで、継承によるカスタマイズを暗示するように設計できます。 すなわち 明確さと階層を失いながら、コンテンツを小さなメソッドに分割します。 このアプローチの欠点は、著者が記事Ideal UI Frameworkで書いています 。

 class MyPanel extends React.Component { header() { return <div class="my-panel-header">{this.props.head}</div> } bodier() { return <div class="my-panel-bodier">{this.props.body}</div> } childs() { return [ this.header() , this.bodier() ] } render() { return <div class="my-panel">{this.childs()}</div> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 class MyPanelExt extends MyPanel { footer() { return <div class="my-panel-footer">{this.props.foot}</div> } childs() { return [ this.header() , this.bodier() , this.footer() ] } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この著者（ @vintage ）は、階層を維持しながら上記の例を説明できるツリー形式を思いついたと言わなければなりません。 多くの人がこの形式を批判しているという事実にもかかわらず、特別な分割やリファクタリングを行わなくても、細部まで再定義できるという利点があります。 言い換えれば、これは無料の（ほとんど、新しい珍しい概念を理解することに加えて）SOLIDの文字Oです。

この原則をJSXに完全に移行することはできませんが、DIを介して部分的に実装することができます。 ポイントは、階層内のコンポーネントは、vueの観点からは拡張ポイント、スロットでもあるということです。 そして、親コンポーネントでは、その識別子（元の実装またはインターフェイス）を知って実装を変更できます。 これは依存関係コンテナの数であり、実装をインターフェイスに関連付けることができます。

js / tsでは、実行時に、複雑さや、コードのセキュリティを損なう文字列キーの導入なしでは、インターフェイスを参照できません。 したがって、次の例はフローまたはタイプスクリプトでは機能しません（ただし、同様の例はC＃またはDartで機能します）。

 interface ISome {} class MySome implements ISome {} const map = new Map() map.set(ISome, MySome)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、抽象クラスまたは関数を参照できます。

 class AbstractSome {} class MySome extends AbstractSome {} const map = new Map() map.set(AbstractSome, MySome)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

なぜなら オブジェクトとコンポーネントの作成はDIコンテナ内で行われ、内部に同様のマップが存在する場合があります。その後、実装を再定義できます。 そして以来 最も原始的なものを除くコンポーネント-関数、それらは同じインターフェースを持つが、異なる実装を持つ関数に置き換えることができます。

たとえば、TodoResetButtonViewはTodoViewの一部です。 カスタム実装でTodoResetButtonViewを再定義する必要があります。

 function TodoResetButtonView({onClick}) { return <button onClick={onClick}>reset</button> } function TodoView({todo, desc, reset}) { return <li> <input type="checkbox" checked={todo.finished} onClick={() => todo.finished = !todo.finished} />{todo.title} #{todo.id} ({desc.title}) <TodoResetButtonView>reset</TodoResetButtonView> </li> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TodoViewを編集する機能がないと仮定します（別のライブラリにあり、触れたくない、オープン/クローズの原則に違反し、古いボタンでそれを使用した11のプロジェクトを再テストします）。

したがって、新しいボタンを作成し、既存のTodoViewを複製して、複製内で置き換えます。 この継承では、可視性のみが侵害されません-階層が維持されるため、ボタンを交換できるようにTodoViewを特別に設計する必要はありません。

 function ClonedTodoResetButtonView({onClick}) { return <button onClick={onClick}>cloned reset</button> } const ClonedTodoView = cloneComponent(TodoView, [ [TodoResetButtonView, ClonedTodoResetButtonView] ], 'ClonedTodoView') const ClonedTodoListView = cloneComponent(TodoListView, [ [TodoView, ClonedTodoView] ], 'ClonedTodoListView') ReactDOM.render(<ClonedTodoListView todoList={store} />, document.getElementById('mount'));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィドル

コンポーネントだけでなく、依存関係も再定義する必要がある場合があります。

 class AbstractHelloService { name: string } function HelloView(props: {greet: string}, service: AbstractHelloService) { return <div> {props.greet}, {service.name} <br/><input value={service.name} onChange={(e) => { service.name = e.target.value }} /> </div> } class AppHelloService { @mem name = 'Jonny' } function AppView() { return <HelloView greet="Hello"/> } AppView.aliases = [ [AbstractHelloService, AppHelloService] ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィドル

HelloViewはAppHelloServiceクラスのインスタンスを受け取ります。 なぜなら すべての子コンポーネントのAppView.aliases



、AbstractHelloServiceをオーバーライドします。

もちろん、継承による「すべてをカスタマイズする」アプローチにはマイナスがあります。 なぜなら フレームワークはより多くの拡張ポイントを提供するため、カスタマイズの責任はコンポーネントを設計するのではなく、コンポーネントを使用するものに移ります。 意味を認識せずに「テーブル」コンポーネントの一部を再定義すると、誤って「リスト」に変えることができますが、これは悪い兆候です。 は元の意味の歪みです （ LSPの原則に違反しています）。

状態分離

デフォルトでは、コンポーネントの依存関係の状態が各コンポーネントに割り当てられます。 ただし、一般的な原則が適用されます。上記のコンポーネントで定義されているものはすべて、基礎となる依存関係よりも優先されます。 すなわち 依存関係が最初に親コンポーネントで使用される場合、依存関係はその依存関係と共に存続し、依存関係を要求したすべての基礎となるコンポーネントは、親インスタンスを正確に受け取ります。

 class HelloService { @mem name = 'John' } function HelloView(props: {greet: string}, service: HelloService) { return <div> {props.greet}, {service.name} <br/><input value={service.name} onChange={(e) => { service.name = e.target.value }} /> </div> } class AppHelloService { @mem name = 'Jonny' } function AppView(_, service: HelloService) { return <div> <HelloView greet="Hello"/> <HelloView greet="Hi"/> </div> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィドル

この構成では、両方のHelloViewがHelloServiceの共通インスタンスを共有します。 ただし、AppViewにHelloServiceがない場合、各子コンポーネントには独自のインスタンスがあります。

 function AppView() { return <div> <HelloView greet="Hello"/> <HelloView greet="Hi"/> </div> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブジェクトがどのコンポーネントに属するかを制御できる場合、同様の原則が格納庫の階層DIで使用されます 。

スタイル

私は、css-in-jsアプローチがWebで使用する唯一の権利であると言っているのではありません。 しかし、ここでは依存性注入の考え方を適用できます。 この問題は、redux / mobxおよびコンテキストに関する上記の問題に似ています。 たとえば、多くの同様のライブラリと同様に、jsスタイルはinjectSheetラッパーを介してコンポーネントに固定され、コンポーネントはreact-jssを使用して特定のスタイル実装に関連付けられます。

 import React from 'react' import injectSheet from 'react-jss' const styles = { button: { background: props => props.color }, label: { fontWeight: 'bold' } } const Button = ({classes, children}) => ( <button className={classes.button}> <span className={classes.label}> {children} </span> </button> ) export default injectSheet(styles)(Button)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、jssなどへのこの直接の依存は、この責任をDIに転送することで削除できます。 アプリケーションコードでは、スタイルを持つ関数をコンポーネントの依存関係として定義し、それに応じてマークするだけで十分です。

 // ... setup import {action, props, mem} from 'lom_atom' import type {NamesOf} from 'lom_atom' class Store { @mem red = 140 } function HelloTheme(store: Store) { return { wrapper: { background: `rgb(${store.red}, 0, 0)` } } } HelloTheme.theme = true function HelloView( _, {store, theme}: { store: Store, theme: NameOf<typeof HelloTheme> } ) { return <div className={theme.wrapper}> color via css {store.red}: <input type="range" min="0" max="255" value={store.red} onInput={({target}) => { store.red = Number(target.value) }} /> </div> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィドル

このようなスタイルのアプローチには、DIのすべての利点があり、テーマと反応性を提供します。 cssの変数とは異なり、flow / tsの型はここで機能します。 マイナス-CSSの生成と更新のオーバーヘッド。

まとめ

コンポーネントの依存性注入の考え方を適応させるために、 reactive-diライブラリーを入手しました。 記事の簡単な例はそれに基づいていますが、読み込み、ダウンロードステータスの処理、エラーなど、 より複雑な例もあります。 反応、事前反応、インフェルノのtodomvc ベンチマークがあります 。 ここで、reactive-diを使用してオーバーヘッドを評価できます。 確かに、100の仕事で、このオーバーヘッドよりも大きな測定誤差がありました。

結果は、簡略化されたAngularです。 ただし、reactive-diには多くの機能があります

1. クリーンなリアクションでレガシーコンポーネントとの互換性を維持しながら、reactおよびそのクローンと統合可能
2. mobx / observeなどで純粋なコンポーネントをラップせずに記述することができます
3. クラスだけでなく、コンポーネント関数に対しても、フロータイプのタイプとうまく機能します
4. 控えめ：コード内にデコレータのヒープは必要ありません。コンポーネントは反応から抽象化され、メインコードに影響を与えることなく実装に変更できます。
5. 構成が簡単で、依存関係の登録が不要で、提供/注入のような構造を提供します
6. 内部の階層を維持しながら、コンポーネントの内容を変更せずに再定義できます。
7. インターフェイスを介してcss-in-jsソリューションをコンポーネントに控えめに統合できます

なぜコンテキストという考え方がまだこのように発展していないのですか？ おそらく、フロントエンドでのDIの不人気は、フロー/ tsのそれほど広くない優位性と、メタデータレベルでの標準インターフェイスサポートの欠如によるものです。 深く再考することなく、他のバックエンド指向言語（C＃のInversifyJSクローンNinjectなど）から複雑な実装をコピーしようとします。 これまでの強調が不十分であるだけでなく、例えば、DIの類似性は反応とビューにありますが、これらの実装はフレームワークの不可欠な部分であり、その役割は二次的です。

良いDIは解決策の半分です。 上記の例では、 @mem



デコレータが頻繁に点滅しました。これは、 PPRのアイデアに基づいて構築された状態を管理するために必要です。 memを使用すると、mobxと比較して単純なエラー処理とブートステータスを使用して、擬似同期スタイルでコードを記述できます。 次の記事で彼についてお話します。