An additional example to clarify the process
A couple of years ago I wrote the article Flutter State Management for Minimalists. In that article, I suggested that you can handle state in your Flutter apps by simply using the built-in tools that Flutter provides rather than third-party state management packages like Provider, Bloc, or Riverpod.
I’m certainly not opposed to those packages. I admire their authors very much. In fact, I’ve considered on several occasions building an app with Bloc, but the thing is, I haven’t needed to. After two years I’m still using the minimalist approach in all my apps. What I like about it is that I know what’s happening and the API has remained stable over the years.
One of the engineers on the Flutter team also endorsed this approach:
The way I do it is to use a ValueNotifier to let the UI know about state changes and a ValueListenableBuilder to rebuild the UI when there’s a change. I keep the UI code in one file and put the state management logic in another file. I explained that in some detail in my original article. That article included a Timer app example, but I’d like to give a…
