Isn‘t riverpod violating the basic sm rules?

[Hasankanso]

Hello everyone,

I learned Provider and I find it pretty easy and straightforward. Now, I'm trying to learn riverpod and understand the differences...

First thing I noticed that providers are declared outside of classes. Isn't that bad? Global states are generally bad practice.
And doesn't it mean that the state will live as long as the app is alive? Which is pretty bad.

Hope you can give me some insight.
Thank you for reading💪
Hassan

[rrousselGit]

And doesn't it mean that the state will live as long as the app is alive? Which is pretty bad.

No, thanks to autoDispose

Global states are generally bad practice.

I would argue that Riverpod providers aren't a global state.

Providers themselves are stateless. They are completely immutable objects. You cannot do things like:

final counter = StateProvider((ref) => 0);

void main() {
  print(counter.value);
  counter.value++;
}

To use providers, you need a ProviderScope/ProviderContainer, which is not available globally. You can't do something like ProviderContainer.instance.read(provider) for example.

Basically, those ProivderScope/ProviderContainers can be considered as a Map where the key is a Provider.

final counter = StateProvider((ref) => 0);

void main() {
  // doing:
  final container = ProviderContainer();
  print(container.read(provider));

  // is similar to:
  final container = <ProviderBase, dynamic>{};
  print(container[counter]);
}

As such, in this case a provider is hardly any different from an int/String.

final counterKey = 'counter';

void main() {
  final container = <Object?, dynamic>{};
  print(container[counterKey]);
}

All int/String variables are available globally too. But that's not a problem, since they are completely immutable.
Since providers are completely immutable too, declaring providers globally is similarly harmless.