More convenient Scoped Provider syntax

[jackpordi]

Is your feature request related to a problem? Please describe.

Whilst I like that Riverpod prevents unsafe reads from unscoped parts of the widget tree like in provider, being able to explicitly define scope within the widget tree is immensely useful, particularly when when dealing with having multiple different providers active in different parts of the screen, or having async dependencies on other providers.

I'm sure you're familiar with React's context API:

// Create the global context object, which is global
const MyContext = React.createContext(defaultValue);

// In the component tree somewhere later
<MyContext.Provider value={scopedValue}>
 // ...child components
<MyContext.Provider>

If a child component tries to access the context's value, if it is a child of the scoped provider, it gets scopedValue, otherwise it gets the default defaultValue.

This is currently already possible with ScopedProvider:

ProviderScope(
      overrides: [
        repositoryProvider.overrideWithValue(FakeRepository())
      ],
      child: MyApp(),
    );

But in my opinion the syntax is a little clunky.

Describe the solution you'd like

Instead of the above syntax, it would be nice if we could instead do something like this:

final helloWorldProvider = Provider((_) => 'Hello world');

// Use as a widget somewhere else
helloWorldProvider.Scope(
  child: // child
 )

Could call it .Provider, .createScope, etc etc as well.

[rrousselGit]

The issue with this proposal is, this means overriding providers would use a different syntax based on whether the override is done in a widget or not

Bear in mind that Riverpod's dependency on Flutter is optional. It's very much possible to use Riverpod without Flutter, and those cases also sometimes want to override providers.

[jackpordi]

The issue with this proposal is, this means overriding providers would use a different syntax based on whether the override is done in a widget or not

Overriding providers already use a different syntax depending on if it's in a widget or not. Doing it in flutter uses ProviderScope, and regular dart uses ProviderContainer with an override property.

[rrousselGit]

Both use the same syntax:

overrides: [
  someProvider.overrideWithValue(42),
]

[jackpordi]

Ok, they both use the same overrides property. Still, I think flutter users of this library will benefit immensely from having more convenient scoping syntax. I'm not advocating for the removal of the current methods, just a more convenient alternative.

[rrousselGit]

Having multiple syntaxes for doing the same thing is generally a bad idea.

Also, the current syntax scales better with overriding multiple providers at once. With your proposal, overriding multiple providers would involve quite a bit of nesting

Similarly when overriding 2+ providers at once, the current syntax hosts the overrides within a single ProviderContainer. Whereas since proposal would involve creating once container per override, which is less efficient

[jackpordi]

Having multiple syntaxes for doing the same thing is generally a bad idea.

Also, the current syntax scales better with overriding multiple providers at once. With your proposal, overriding multiple providers would involve quite a bit of nesting

Similarly when overriding 2+ providers at once, the current syntax hosts the overrides within a single ProviderContainer. Whereas since proposal would involve creating once container per override, which is less efficient

Again, I am NOT proposing you get rid of the current syntax. I'm simply proposing a syntactic sugar alternative for the use case of 1 override.

There are many instances where only one override is necessary, and in instances where overriding 2+ providers then the current method should be used (and documentation should make it abundantly clear which is appropriate). The way I see it, it's akin to to Provider and MultiProvider - peaceful coexistence for slightly different use cases.

[rrousselGit]

I'll close this as I don't plan on implementing it.
My goal is to reduce the API surface of Riverpod. Introducing competing syntaxes would increase the learning curve, which is the opposite of what I want.

If you want this, you can still do it on your own with extensions. It's not as convenient as if I did it for you, but you still can have it.