The Riverpod 'Global' Myth

Randal Schwartz debunks the "Riverpod is all globals" myth, describing several levels of scoping to get to providers.

Support Randal on Patreon via

[clragonite]

so the arguments this video makes to proof that riverpod is "not all global" are:

- we have namespace scope, but this is not used in 95% of all cases
- we have widget tree scope like provider, but its hard to use and only for testing
- we have families which are essentially like global Map<String, dynamic>

I am not convinced.

[bzark]

Correct me if I'm wrong but class static locals is not possible if using Riverpod code generation. The reason I bring that up is because the Riverpod documentation states that code generation syntax will be the only syntax available in Riverpod down the road.

[ilya_]

Wait a minute, is he saying provider is a state management? How come? Even Remi himself ask people long time ago to not call the Provider a state manager.

[HillelCoren]

Thanks for making this video, it was very helpful!

[TreyHope]

Thanks Randal for sharing, very informative

[fluttera]

Hello Randal, i am following your videos and think they have a great value for flutter developers. Thanks for sharing your knowledge!

[hojdog]

Why would it matter if the providers are defined globally? I’ve always thought the issue is with testing but here you’re talking more about scope. You can’t modify them if you’re using final, so where would the problem even lie?

I use riverpod heavily and love it.

I don’t really like this family keys solution though, I do find nesting ProviderScope clunky as it makes working with provider dependencies difficult, but I don’t like this solution of having to pass global keys down the widget tree :(

[handsanitizer]

Thanks i appreciate this, many people dodge riverpod because of these myths. When its been great, i have two products in production using it. And its been working fine. Except in cases where I've used it incorrectly

[fjk]

Thank you always for your great resources. I am a fan of Riverpod as well, but I wasn't really convinced of the three axes of scope explained here 🤔. Allow me to check my sanity by describing my thoughts below 🙏🏻

- Namespace: Class static local providers can be still accessed from anywhere in the app, in which sense, it still is in the global scope. However, it is indeed a handy way to establish a mental model as to which provider can be accessed from which part of the app.
- Ref (ProviderScope): This gives "true" scope in my mind because there is no way to access a provider outside the provider scope. However, as explained, it is only intended for tests
- Family: It is an interesting usage but I don't think this is a true scope either. Similar to the class local providers, it offers a nice mental model, but it doesn't offer something like compiler/runtime protection against violating the scopes. (How I understood the usage: you can create a provider with ID1 and ID2 for example, and from some parts of the app, you will only access the provider with ID1, and from another part of the app, you will access the provider with ID2. This gives you a nice mental model to separate the providers but you CAN access both providers from anywhere if you want.)

So, in all, I am not very convinced that Riverpod offers true scopes.

But then, I don't quite understand the "global is bad" rant either. The app state which is common to multiple parts of the app, is naturally global (To support my point, the once very popular Redux is a global state). Some states might be very narrowly scoped like only to a widget. But StatefulWidget is there exactly for that. For stuff in between, we can use the above technique to establish a clean mental model even though it does not offer "true" scope. The "global state" discussion itself is not that big of a deal if you allow me to speak. (I mean, it's NICE to have a scoped state)

Do I have a sane mind here? Am I understanding this video properly? Anybody/any feedback is appreciated 🙏🏻

[MrVipulLal]

Granted. But these are workarounds. There isn’t a single advantage of riverpod over provider or inherited widget.