search

kranfix / riverbloc

`flutter_bloc` implemented with `riverpod` instead of `provider`.
83 stars 17 forks source link

Pure riverpod flutter_hooks_bloc package (No dep on flutter_block) #35

Closed tlvenn closed 3 years ago

tlvenn commented 3 years ago

Hi @kranfix,

Thanks a lot for your work on integrating blocs with riverpod !

At the moment, i am looking at using cubits & blocs with riverpod with the Bloc widgets using the river factory (so not using hooks) and there is a little bit of friction on the BuildContext helper method read given both riverpod and flutter_block are competing with their extension. I tried to hide the provider extension but for some reason, it did not work so instead i am forced to be explicit with the extension i want to use such as BuildContextX(context).read()

Would it be possible to publish a package that is free of flutter_bloc but one that does provide BlocBuilder.river(), BlocListener.river() and BlocConsumer.river() constructors ?

kranfix commented 3 years ago

Can you explain what exactly are you trying to do?

tlvenn commented 3 years ago
image

Ideally i would like to be able to simply do onChanged: (username) => context.read(loginCubitProvider).updateUsername(username)

tlvenn commented 3 years ago

So just to clarify the ask a little bit, I am wondering if it would be possible to split the current flutter_hooks_bloc into 2 packages, like flutter_hooks_bloc depending on flutter_block & flutter_hooks_riverbloc depending on flutter_riverpod.

Then depending on if you wish to use riverpod or the provider, it will only import the right BuildContext extension instead of both.

Or maybe it does not have to be 2 packages but 2 entrypoints in the same library so depending on which one you import it will import one extension or the other ?

kranfix commented 3 years ago

It is possible, I'll consider it.

kranfix commented 3 years ago

@tlvenn I think it is not possible because there are many conflicts between provider and riverpod packages.
Both have context.read() and Provider class.

One solution is to reexpose providers context.read() as  context.iread() where the i refers to InheritedProvider.

tlvenn commented 3 years ago

I have tested that the submitted PR works.

tlvenn commented 3 years ago

As pointed out in the PR, turns out the other already existing entrypoint for the library solves this. It probably should be documented 🤣