Skip to content
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

Have providers extend each-others. Then deprecate ProviderBase #3904

Open
rrousselGit opened this issue Jan 6, 2025 · 0 comments
Open

Have providers extend each-others. Then deprecate ProviderBase #3904

rrousselGit opened this issue Jan 6, 2025 · 0 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@rrousselGit
Copy link
Owner

It would be significantly helpful if the core providers subclassed each-others:

class Provider<T> {}

class FutureProvider<T> extends Provider<AsyncValue<T>> {}
typedef AsyncProvider<T> = FutureProvider<T>;
class StreamProvider<T> extends AsyncProvider<T> {}


class NotifierProvider<Notifier, T> extends Provider<T> {}
class AsyncNotifierProvider<Notifier, T> extends NotifierProvider<Notifier, AsyncValue<T>> {}
class StreamNotifierProvider<Notifier, T> extends AsyncNotifierProvider<Notifier, T> {}

We could then deprecate ProviderBase in favour of Provider itself.

The benefit of such change is that it enables folks to easily add extension methods to providers/ref, while having access to .future/.notifier when it makes sense.

This avoids having to introduce interfaces for "Providers with a .notifier or .future property"

@rrousselGit rrousselGit added the enhancement New feature or request label Jan 6, 2025
@rrousselGit rrousselGit self-assigned this Jan 6, 2025
@rrousselGit rrousselGit added this to the Riverpod 3.0 milestone Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant