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

feat: ability to override a bloc/cubit/repository in the tree. #3671

Closed
YazeedAlKhalaf opened this issue Dec 25, 2022 · 3 comments
Closed

feat: ability to override a bloc/cubit/repository in the tree. #3671

YazeedAlKhalaf opened this issue Dec 25, 2022 · 3 comments
Labels
dependency This issue has an external dependency question Further information is requested

Comments

@YazeedAlKhalaf
Copy link

Description

It is frustrating that I have to split code to multiple parts to get around the fact that I can't just override a bloc provider.
Sometimes in testing, it makes that testing task a nightmare and the code untestable.

I think this is one missing feature that will make the life of a lot of developers including me, you and everybody easier.

Desired Solution

A BlocOverrides/RepositoryOverrides widget that overrides any Bloc/Repository in the tree under it. Something similar to how ProviderScope works.

Alternatives Considered

I tried splitting the providing code to a separate widget and the ui code in a different widget but that does not work for example when testing a bottom sheet opening from another screen since i use the widget that has bloc provider.

@felangel
Copy link
Owner

Hi @YazeedAlKhalaf 👋
Thanks for opening an issue!

BlocProvider and RepositoryProvider rely on package:provider. This sounds like a feature request for package:provider and I highly recommend moving this issue to the provider GitHub repository. Let me know what you think, thanks!

@felangel felangel added question Further information is requested waiting for response Waiting for follow up dependency This issue has an external dependency labels Dec 27, 2022
@YazeedAlKhalaf
Copy link
Author

why don't we migrate to riverpod in a breaking version?

@felangel
Copy link
Owner

why don't we migrate to riverpod in a breaking version?

See #2100.

Closing for now since there are no actionable next steps on the bloc repo here.

@felangel felangel removed the waiting for response Waiting for follow up label Dec 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependency This issue has an external dependency question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants