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 回だけ作成されます。メモリリークの可能性はありますか?