-
-
Notifications
You must be signed in to change notification settings - Fork 951
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for comments: Should all providers be merged into one? #39
Comments
I agree with the proposal. |
For my current project I started to do final myProvider = createProvider.stateNotifier.family<T, Fam>((r, f) => .. ); by just using callable classes :) |
I've just realised that we can't implement So this reinforces the idea of keeping |
Personally i would prefer Retry over anything else :P |
Another alternative is to do like @smiLLe suggested and go for This will allow using extensions to add custom members. And to begin with, we don't care about const constructors, so this using a function over a constructor doesn't matter. |
I'll go for It'll then be accompanied by:
|
I like how composable the modifier idea is. It allows implementing commonly wanted features almost without doing anything. Do you have any modifiers in mind that I haven't mentioned yet? Currently we'd have:
What other big feature would we want? 🤔 |
@rrousselGit Some kind of logging mechanism? Not sure if that is possible, just sharing the idea 😅 |
Logging in implemented directly on ProviderScope(
observers: [
LoggerObserver(),
],
child: MyApp(),
);
class LoggerObserver extends ProviderStateOwnerObserver {
...
} Although maybe we could have an "onChange" on providers individually |
Do you know recoil js? It is very similar to riverpod :) Maybe we can take some inspiration from them. |
I do. Finding Recoil made me rename Anyway, we'll see later. I'll focus on retry/restorable. There's a bunch of work to do on for the provider code-generator |
I would agree that the change in name convention makes a great deal of sense here. |
Hello and thanks for reading!
This issue is about slightly changing the syntax of how provider variants are created.
Feel free to comment and share your opinion on the matter!
The problem
Currently, we have many classes, which are all basically the same modulo a small name + prototype change.
The current syntax is a permutation of:
For a total of 24 variants.
With a secondary table for
Computed
.But that's not very ideal:
AutoDisposeChangeNotifierProviderFamily
The last point is especially important, as ideally, I would like to add new variants:
Future
/Stream
in a separate column, such that we could have aFutureStateProvider
for exampleWhich means the table of variants would become:
That leads to a ridiculous 128 providers
The Solution
The idea is to merge all the variants into two public classes:
Provider
andComputed
.Riverpod would still have 128 providers internally, but they would be code-generated so it doesn't matter for end-users.
The way this new syntax would work is using the Builder design pattern.
Basically, instead of:
We would have:
Whereas:
would become:
And
Provider((ref) => Object())
would be untouched.The difference:
package:riverpod/providers.dart
).stream
and.autoDispose
.Questions
Should some provider variants stay as is, such that we would still have
StateProvider(...)
instead ofProvider.state(...)
?If so, what are the providers that we want to keep this way? I'm thinking of:
And then for fancier versions like
FutureStateNotifierProvider
would becomeStateNotifierProvider.future
.The text was updated successfully, but these errors were encountered: