Exploring Dart/Flutter Riverpod Lifecycles

Flutter architecturally is pretty agnostic about how one wires the state and business logic into the Flutter UI. It has no “standard” way of doing it although it does provide the foundational architecture to build declarative UIs. Most people use a framework on top of that to achieve it in a more intuitive and streamlined way. One such popular framework is Riverpod , “A Reactive Caching and Data-binding Framework”. I’ve recently switched from another framework to this and have enjoyed the experience a lot. However there are some nuances to the nature of the lifecyle of the components which I have found myself getting confused on half way through an implementation. These aren’t complicated concepts when looked at in isolation. It’s just something that I keep having to “relearn” if I haven’t seen it in awhile. I thought it’d be good to document it for myself, and by extension for anyone else. This won’t cover the basics of Riverpod like setup, design pattern best practices, et cetera. except as needed to explore the concept of the lifecycle of the Riverpod components. Also, I am not a Riverpod expert so this is my relative new-to-the-framework point of view as well. If anything stands out to experts as being an over-simplification to the point of being wrong or adding confusion to what is happening please ping me on my socials. You can find the completed demo in this GitLab repo directory