5

HOC (具体的には react-graphql )の引数をカスタマイズしようとしています。この特定のライブラリ HOC の動作方法により、HOC が呼び出された後にコンポーネントの状態 (クエリとオプション) に影響を与えることはできません。

Redux のような従来の HOC ファクトリconnect()では、含まれているすべてのロジックがすぐに適用されますが、これは私たちには早すぎます。applyOriginalHOC()代わりに、このコンポーネントから最初のインスタンスが構築されるまで、元の HOC ( ) の適用を延期しています。

export function applyLazyHOC(args) {
  return function wrap(WrappedComponent) {
    let ComponentWithLazyHOC; // Closed-over value is scoped to component
    class LazyHOC extends Component {
      constructor() {
        super();
        // Lazy initialising of HOC to give customisations an opportunity to be registered
        if (!ComponentWithLazyHOC) {
          ComponentWithLazyHOC = applyOriginalHOC(
            // Adds customisations which have been registered by third party code
            myCustomization(args)
          )(WrappedComponent);
        }
      }
      render() {
        return <ComponentWithLazyHOC {...this.props} />;
      }
    }

    return LazyHOC;
  };
}

少し型破りなアプローチのように思えるので、フィードバックを探しています。

  • HOC の初期化順序を変更することによる副作用はありますか? HOC は、他の HOC の存在に依存すべきではないと思います。
  • いずれにせよ、静的解析 (IDE など) は HOC では不可能なので、遅延評価によってこれが良くも悪くもなりませんよね?
  • HOC はcontext、ネストされたコンポーネント全体に蓄積される React コンポーネントに提供できます - 順序は重要ではありませんよね?
  • コンポーネント定義はアンロードされることはなく、ComponentWithLazyHOCコンポーネント (コンポーネント インスタンスではなく) ごとに 1 回だけ作成されます。メモリリークの可能性はありますか?
4

0 に答える 0