Today the bloc library is officially two years old! 🎉
With over 5,700 stars, 1,200 commits, and countless hours spent building and fixing issues, it's been quite a journey so far. It has even been named a Flutter Favorite!
Bloc truly would not be the highly-rated library it is today without valuable contributions from developers around the world. To celebrate, I thought I would share some thoughts about bloc’s evolution and managing a popular open source library.
How Bloc Began
I started the bloc library in 2018 to fill a need for a scalable, reliable state management solution. I had read about the BLoC pattern and decided that this would be the ideal approach, but could not find a library in Flutter yet that enforced it. So I decided to make my own!
My colleagues and I planned to use it only internally, but the more I thought about it, the more I realized others could benefit too. I open sourced bloc so that others could use it to solve the same state management issues we were facing.
Bloc’s popularity has since skyrocketed and I dedicate a lot of my free time to maintaining the library and adding new features.
Thorough Documentation or Bust
One thing that has become abundantly clear over time is that building something useful is only half the battle. In order for users to get the most value out of a library, the documentation must be clear and thorough. I think it’s also really helpful to make documentation that is interactive and easy to follow for developers of all backgrounds and skill levels.
Keeping the documentation alongside the project source code has been valuable because I can ensure that all documentation and sample applications always reflect the latest version of the library. Over time, useful content like an FAQ section, migration guides, community articles, and video tutorials have also made their way into the mix.
Testing is Non-Negotiable
Testing should be the foundation of development in general (it has saved me numerous times from accidentally introducing bugs in the bloc library and potentially breaking the thousands of apps that rely on it). With Flutter, there really is no excuse not to test, since testing is built into the framework.
I insisted on following a test-driven approach to writing code for the bloc library as well as automating testing requirements for all contributions from the community. In addition to ensuring that bloc was really well-tested as a library, I created the bloc_test package to make it easy for developers to easily test their own blocs as their codebase grows.
Bloc is a Community Effort
One of the major benefits of maintaining an open source library is the built-in support network of dedicated developers. I know I can turn to the Flutter Community whether I’m looking for quick and helpful feedback, planning major updates, or looking for help answering others’ questions. I even created a dedicated bloc Discord server for anyone looking to troubleshoot or just see what others are working on.
Sometimes it can be difficult to balance other developer’s suggestions with my vision for the future of the bloc library, especially when users are looking for personalized solutions that simply aren’t broad enough to incorporate into bloc.
At the end of the day, I want all developers to find the bloc library useful, so before making any changes, I always ask: Does this change align with my long-term vision of the library? Will this change benefit the larger community?
Future of Bloc (+ Cubit)
A few months ago I started working on cubit, a subset of the bloc library, which has since attracted a lot of attention due to its simplicity.
I initially intended bloc to be used only when transforming incoming events into outgoing states, but soon noticed that the concept of events was somewhat abstract and many developers preferred to use functions as a way to trigger state changes instead.
The more I thought about it, the more it seemed like a good idea to decompose a bloc into a smaller component (known as a cubit) which eliminates events altogether, while still allowing developers to decouple their business logic from the UI layer.
In the latest version of bloc (v6.0.3), bloc extends cubit making it possible to use the two almost interchangeably in a single codebase. Cubit is great for managing simple state because it is a lightweight, less verbose simplification of bloc. Bloc shines with event-driven architecture or when events need to be buffered, throttled, or debounced. With cubit and bloc together in the same library, developers have more flexibility when choosing how to manage their application state.
Since the latest major release, a new package has joined the bloc ecosystem: replay_bloc which introduces and includes support for undo/redo capabilities. Replay_bloc integrates with both blocs and cubits for a seamless development experience.
What's Next
I'm still working on revamping the tutorials and example apps to illustrate how bloc can be used to build production-quality code. Each of the examples will be fully tested and serve as very good jumping off points for developers to build upon.
I can't believe it's been two years since I released bloc into the wild! I hope to keep the momentum going and continue to build high-quality open source software with colleagues and friends from around the world.
Check out the bloc library here and follow me on Twitter @felangelov for the latest news on bloc and other open source projects!
Scarlett Wardrop contributed to this article.
.png)
.png)