riverpodでProviderをグローバル変数で定義するデメリット

Question

riverpodでProviderをグローバルに定義する部分があると思いますが、公式ドキュメントにある説明がちょっと腑に落ちません。

Do not be frightened by the global aspect of providers. Providers are fully immutable. 
Declaring a provider is no different from declaring a function,
 and providers are testable and maintainable.

providerは完全に不変であると言っているのですが、stateの更新など、変更の可能性は多くありそうに思えます。
更新時に変更されるとグローバル変数においている分どこから更新されるかわからずに、逆に扱いづらい気もするのですが、これはデメリットにはならないのでしょうか？

Answer 1

Riverpodの目的の一つに「アプリの様々な場所からステートにアクセスできるようになります。」が入っているので、どこからでもアクセス可能ということにデメリットを感じているのであれば使わない方がいいのではないでしょうか。
パッケージ設計者はその点をメリットの一つとして考えているのだと思うので。

もしアクセス制限をするのであれば、実装ルールを設けたり、ProviderObserver派生を作って監視するとかしかないのかも。

Answer 2

今更ですがたまたま見かけたので3つに分けて回答させていただきます。
残念ながらベストアンサーの方が間違っているので惑わされないように...

1

まず１番重要なポイントとして、providerがstateを直接持っているわけではありません。
ですので「stateは変化するがproviderは不変である」という説明にも矛盾はありません。
実際にソースコード内でも final provider ... のように final修飾子を付けて不変に定義します。

2

またproviderはグローバルなのでどこからでもアクセスできますが、
stateへのアクセスには必ず「Ref」というものが必要になります。
ですので、どこからでも更新されるという解釈も間違いです。

3

最後に「誰がどこから変更したか」を気にしなくても、
データ不整合が起こらないように安全に管理してくれる仕組みになっているので、
質問者様がデメリットとおっしゃっていることは、むしろメリットになります。
質問者様の心配している方向性は正しいですし、
それを「俺に管理を任せろ！」といっているのがまさにriverpodです。
いらなくなったstateが自動的に消える仕組み等も用意されています。

以上回答になります。長文失礼しました。