Motivation
When you want to use Bloc/Cubit in your application you have to provide an instance of the object down the widgets tree for state receivers. This is mostly achieved by BlocBuilder along with BlocProvider and enlarges complexity of the given widget.
Each time you have to use BlocBuilder, BlocListener or BlocSelector. What if we could use the power of Flutter hooks?
So, instead of this:
We can have this:
This code is functionally equivalent to the previous example. It still rebuilds the widget in the proper way and the right time. Whole logic of finding adequate Cubit/Bloc and providing current state is hidden in useBloc and useBlocBuilder hooks.
Full example can be found in here
Setup
Install package
Run command:
Or manually add the dependency in the pubspec.yaml
After that you can (it’s optional) initialize the HookedBloc:
Then you can simply start writing your widget with hooks:
Basics
Existing hooks
Hooked Bloc already comes with a few reusable hooks:
| Name | Description |
| useBloc | Returns required Cubit/Bloc |
| useBlocFactory | Returns desired Cubit/Bloc by creating it with provided factory |
| useBlocBuilder | Returns current Cubit/Bloc state – similar to BlocBuilder |
| useBlocListener | Invokes callback – similar to BlocListener |
| useActionListener | Invokes callback, but independent of Bloc/Cubit state |
useBloc
useBloc hook tries to find Cubit using the cubit provider, or – if not specified – looks into the widget tree.
useBlocFactory
useBlocFactory hook tries to find factory using provided injection method and then returns cubit created by it
useBlocBuilder
useBlocBuilder hook rebuilds the widget when new state appears
useBlocListener
useBlocListener hook allows to observe cubit’s states that represent action (e.g. show Snackbar)
useActionListener
useActionListener hook is similar to the useBlocListener but listens to the stream different than state’s stream and can be used for actions that require a different flow of notifying.
Because of that your bloc/cubit must use BlocActionMixin
Then, consume results as you would do with useBlocListener
Contribution
We accept any contribution to the project!
Suggestions of a new feature or fix should be created via pull-request or issue.
feature request:
- Check if feature is already addressed or declined
- Describe why this is needed
Just create an issue with label
enhancementand descriptive title. Then, provide a description and/or example code. This will help the community to understand the need for it. - Write tests for your hook
The test is the best way to explain how the proposed hook should work. We demand a complete test before any code is merged in order to ensure cohesion with existing codebase.
- Add it to the README and write documentation for it
Add a new hook to the existing hooks table and append sample code with usage.
Fix
- Check if bug was already found
- Describe what is broken
The minimum requirement to report a bug fix is a reproduction path. Write steps that should be followed to find a problem in code. Perfect situation is when you give full description why some code doesn’t work and a solution code.
- Write tests for your hook
The test should show that your fix corrects the problem. You can start with straightforward test and then think about potential edge cases or other places that can be broken.
- Add it to the README and write documentation for it
If your fix changed behavior of the library or requires any other extra steps from user, this should be fully described in README.
