Provider タワーを Recoil に置き換える記事読んだ

ProviderタワーをRecoilに置き換える

読んだ。

まず Provider は、

Providerは、コンテキストに対して値を供給する役割を担っており、コンポーネントツリー内でProviderより内側に配置されたコンポーネントからはそのコンテキストの値を参照することができます。コンテキストは、Reactにおいて外部ライブラリを使わずにステート管理（特にアプリ内の複数箇所で値を共有すること）を行うために使われます。

こう。

コンテキストが増えて大量のコンテキストを使いまくっている状態を Provider タワーと言っている。

だけど、

コンテキストの使用量が増えることそれ自体は、必ずしも悪いことではありません。Providerがたくさん並んでいるのは見た目が悪い気もしますが、それ自体が問題というわけではありません。

別にそれは悪いことではない。

問題となるのは、Providerの間に依存関係が生まれた場合です。

なるほど。

記事の例を見れば分かるように、内側のコンテキストが外側のコンテキストに依存しているという状態が発生してしまったりする。

コンテキスト間の依存関係はこのようにコンポーネントツリー上で表現されなければならず、コンテキストの実装そのものではなくコンテキストの使用者側に委ねられています。これは、コンテキスト間の依存関係が、コンテキスト内でどの別のコンテキストから値を取り出しているかということを通じて、暗黙にしか表現されていないからです。

コンテキストの実装で依存関係を見る(あるコンテキストから別のコンテキストの値を取り出す)のと、コンポーネントツリーでの依存関係の表現でそれぞれ分散してしまっているということみたい。

RecoilはReactのコンポーネントツリー外にデータフローグラフを構築することができます。これはちょうどProviderタワーの進化系として考えることができ、Providerタワーと似たようなモデルを採用しつつ、その間の依存関係を明確にすることができるのです。

Recoil すごい。

Recoilを用いた実装では、atomとselectorが直接明示的に接続されており、コンポーネントツリーに依存しません。これがRecoilを用いてデータフローグラフを構築することの、Providerタワーに比べた利点です。

それでいて、複数のコンテキストが各々の責務を持っており依存しあっているというモデルは、Recoilに移行しても保たれています。この点がProviderタワーからRecoilに移行する際には魅力的です。

なるほど、分かりやすい。

コンポーネントツリーでの依存関係の表現から解放されつつ、コンテキスト実装間の依存関係は selector を使うことで表現できる。これなら Provider からも移行しやすそう。

使っていきたい。