An Alternative To Flutter State Management Anti-Patterns

State management in Flutter is the transfer of global state to local state, for example the scroll controller gets initialized in the shared scaffold, but we transfer its position to a local widget to do reveal effects upon scrolling to that widget as it appears in the viewport. What if there was an easier way to make it more modular and easy to implement?

The Elephant In The Room

Most front-end frameworks use a State object to give us designers an API interface to the view lifecycle that the framework uses to render the views. The JavaScript React framework does not, as the render framework is actually the browser itself, and it’s the only front-end framework that does not follow that pattern.

And so the antipatterns arise in dealing with how to interact with that State object. So of the antipatterns of flutter state management arise out of re-using an OOP pattern of state management from other frameworks. For example, the both the IoC DI and Non-widget DI suffer from their own problems of not metrics viewable in the Dart DevTools and locking dependencies together in an opaque container.

IoC DI has the added performance hit of it’s not lazy loading components, and so initializing such an IoC in the MaterialApp block means that we get this huge amount of…