Last updated 138 days ago by Andrea Bizzottoflutter
State management is a hot topic in Flutter right now.
Over the last year, various state management techniques were proposed.
The Flutter team and community have not (yet) settled on a single “go-to” solution.
This makes sense, because different apps have different requirements. And choosing the most appropriate technique depends on what we’re trying to build.
Truth be told, some state management techniques have proven very popular.
[ChangeNotifier](https://api.flutter.dev/flutter/foundation/ChangeNotifier-class.html)to propagate state changes across widgets.
Having multiple choices can be a good thing.
But it can also be confusing. And choosing a technique that will work and scale well as our apps grow is important.
What’s more, making the right choice early on can save us a lot of time and effort.
Over the last year I’ve been building a lot of Flutter apps, big and small.
During this time, I have encountered and solved many problems.
And I have learned that there is no silver bullet for state management.
However, after building things and taking them apart over and over, I have fine-tuned a technique that works well in all my projects.
So in this article I introduce a new architectural pattern that I have defined by:
Before we see what this pattern looks like, let me define some goals.
This pattern should:
Out of the existing state management techniques for Flutter, this pattern builds most heavily on BLoCs, and is quite similar to the RxVMS architecture.
Without further ado, I am pleased to introduce: