What’s New in flutter_bloc 0.19.0
Hey everyone! I’m excited to announce flutter_bloc v0.19.0 which includes several features requested by the community with an emphasis on developer experience improvements and boilerplate reduction.
Before jumping into the updates, I’d like to give a big thank you to everyone who gave feedback, created PRs, and reported issues; we couldn’t have done it without your contributions.
Now without further ado, let’s check out what’s new!
BlocProvider Improvements
Until recently, the general rule of thumb was the widget creating a bloc had to be a StatefulWidget in order to instantiate the bloc and dispose of it. This led to lots of boilerplate code that was also particularly error-prone (easy to forget to dispose a bloc or instantiate within a build method, etc…). There were even members of the community who created extensions such as flutter_bloc_extensions to try to address some of these concerns. We’re pleased to announce that your feedback has been taken into account and BlocProvider will now handle automatically disposing of blocs for you.
There are currently two ways to use BlocProvider.
You can instantiate and provide a bloc using the default constructor:
Previously we’d have to do something like this:
As you can see, we no longer have to worry about disposing our blocs! As long as they are created by BlocProvider they will be disposed by BlocProvider automatically 🎉.
The second way to use BlocProvider is using the value constructor:
In the above snippet, we are making an existing instance of MyBloc available to the MyPage widget which is being pushed as a new route via the Navigator. In this case, we’re providing an existing instance of MyBloc and we don’t want MyBloc to be disposed when MyPage is disposed because it is being used in other parts of the application. As a result, we can use the value constructor in order to provide an existing bloc instance to a widget and the bloc will not be disposed. You can check out the route access recipe for more details.
To recap, if you’re creating and providing a new bloc instance to a subtree, you can use the default constructor with builder to create the bloc instance and BlocProvider will handle automatically dispose the bloc. If you want to provide an existing bloc instance to a subtree, you can use the value constructor of BlocProvider and BlocProvider will not dispose the bloc automatically (leaving it up to the BlocProvider higher up in the widget tree which created the bloc to dispose it).
You should no longer need to write any StatefulWidgets for managing your blocs 🎉
MultiBlocProvider (was BlocProviderTree)
MultiBlocProvider is a Flutter widget that merges multiple BlocProvider widgets into one.
MultiBlocProvider improves the readability and eliminates the need to nest multiple BlocProviders.
By using MultiBlocProvider we can go from:
to:
In both cases, we are providing BlocA, BlocB, and BlocC to ChildA; however, with MultiBlocProvider we can do so without the additional nesting which helps keep the code easy to read.
Repository Provider (was ImmutableProvider)
A new type of provider has been introduced which specializes in making repositories available to the widget tree. Please check out the architecture section of the bloc library docs for more information on what a repository is and why it’s useful.
At a high level a repository is a wrapper around one or more data providers with which a bloc communicates. As a result, it’s important to be able to provide and access repositories throughout the widget tree and with the latest updates it’s easier than ever.
To create and provide a new repository we can use the default RepositoryProvider constructor like so:
In the above snippet, we are making an instance of MyRepository available to MyChild and its subtree. As a result, further down the widget tree we can create an instance of MyBloc (which has a dependency on MyRepository) by accessing the instance of MyRepository using RepositoryProvider.of. You’ll notice the API is very similar to that of BlocProvider with an attempt to make the library as intuitive and easy to use as possible.
MultiRepositoryProvider (was ImmutableProviderTree)
MultiRepositoryProvider is a Flutter widget that merges multiple RepositoryProvider widgets into one.
MultiRepositoryProvider improves the readability and eliminates the need to nest multiple RepositoryProviders.
By using RepositoryProvider we can go from:
to:
In both cases, we are providing RepositoryA, RepositoryB, and RepositoryC to ChildA; however, with MultiRepositoryProvider we can do so without the additional nesting which helps keep the code easy to read.
Integration with Provider
You may have noticed that the new BlocProvider and RepositoryProvider APIs look very similar to the provider APIs. A big part of the changes introduced in v0.19.0 were to use provider under the hood so that developers can have a single dependency injection library with a consistent API. Special thanks to Remi Rousselet for all of his feedback and patience 🙏
flutter_bloc will still continue to have specialized providers (as it’s an opinionated library) but we’re excited to be using provider so that we don’t have to maintain our own InheritedWidget wrapper and so we can benefit from all future improvements/features that come with upcoming provider releases.
You can check out the complete change log for more information and as always you can support me by ⭐️the repository, or 👏 for this story.
