Widgets in the UI layer are free to call sync or async methods defined by blocs or services, and can subscribe to streams via StreamBuilder. In this case we need a StatefulWidget because TextEditingController introduces side effects ( I discovered this the hard way), but we are not managing any state explicitly. Widgets can be stateless or stateful, but they should not include any explicit state management logic.Īn example of explicit state management is the Flutter counter example, where we increment the counter with setState() when the increment button is pressed.Īn example of implicit state management is a StatefulWidget that contains a TextField managed by a TextEditingController. Next, let's define some rules for what each layer can (and cannot) do. The service layer (optional): this is what we use to communicate to external services.The data layer (optional): this is where we add our logic and modify state.The UI layer: this is always necessary as it is where our widgets live.
Now, let's explore the full implementation with a more detailed diagram:įirst of all, this diagram defines three application layers: In other words: you can use or omit them as appropriate on a case-by-case basis. NOTE: aside from the Widget item, the BLoC and Service items are both optional. This architectural pattern comes in four variants. Shorthand: WABS (which is cool because it contains my initials :D) Without further ado, I am pleased to introduce: The Widget-Async-BLoC-Service Pattern Out of the existing state management techniques for Flutter, this pattern builds most heavily on BLoCs, and is quite similar to the RxVMS architecture.
Learn more about why – and how – to implement protections, like comprehensive code hardening and anti-tampering capabilities, to protect your Flutter apps with Guardsquare. Help me keep it that way by checking out this sponsor: What's more, making the right choice early on can save us a lot of time and effort.Ĭode with Andrea is free for everyone. And choosing a technique that will work and scale well as our apps grow is important. Having multiple choices can be a good thing.īut it can also be confusing.
Most recently at Google I/O, the Flutter team showed us how to use the Provider package and ChangeNotifier to propagate state changes across widgets.BLoCs are also widely used, and they work well with Streams and RxDart for more complex apps.Scoped Model is known for its simplicity.Truth be told, some state management techniques have proven very popular. And choosing the most appropriate technique depends on what we're trying to build. This makes sense, because different apps have different requirements.
The Flutter team and community have not (yet) settled on a single "go-to" solution.
Over the last year, various state management techniques were proposed. State management is a hot topic in Flutter right now.