State Management Mania
State Management: Abridged Beyond the Point of Usefulness
Client state management, as a concept, wasn’t in the popular programming zeitgeist until the age of web development. Arguably, most of the good software practices started to really be in use at that time as well. Prior to it, the concept of modularly creating reusable components was only used by the top developers. Most of the codebases I look at prior to that period (~2005 or so) tend to be spaghetti string code strung together with the singular focus of making the applicaiton work.
That all changed with Ruby on Rails and it’s introduction of the Model View Controller framework. In the Rails framework, this was just a way to conceptually describe the web brower, HTML, and CSS rendering (View), how the application could be dynamically updated by calling API endpoints with Javascript without a reload needed (Controller), and the SQL database tables and code classes they are mapped to in the object relational mapping (Model). However, people have extended this concept to apply to data within the client side application as well. This means treating some part of client memory and/or local client storage like a database and segmenting code according to the responsibility. In MVC this means that memory object storage is the model, model mutation and other calculations are the controller, and the view is solely responsible for taking model input and generating the UI.
Why is this Important?
Almost every state management solution is extremely opinionated on how code should be structured for a well architected application. There are a whole gaggle of acronyms for MVC adjacent alternatives: HMVC, MVVM, MVP, MVA to name a few. Anthony Ferrara has an interesting blog article on this. Even though it is almost 10 years old, the conclusions hold true to today. Interestingly, they all agree that there is a view and a model, they just disagree on the nature of and how to implement business logic and model mutations.
Having this rigid adherance to a certain set of rules helps to contrain the solution space and make it easier to structure a project which is easy to collaborate on. This is something I found out, as always, the hard way.
Flutter and State Management
Flutter has a list of official state management solutions. Some of them are even the same as the ones for the javascript frameworks like Mobx and Redux.
—
Why State Management
State management isn’t something you hear discussed much until the age of the web application. In particular, the web was unique in that Javascript embraced asynchronous event loops and was an imperative language in the global scope. Most other frontend programming languages used object oriented programming as it make intuitive sense that visual objects on the screen should encapsulate state and behavior in a class. This and the fact that most languages have a concept of static classes enable a simple way to segregate data: data local to the component is stored in a class, data needed on the global scope can be stored in a static class.
Unfortunately for Javascript, there is no concept of classes and singletons. The closest thing to singleton is to declare a const object in the global scope. That and several developers coming into Javascript came from object oriented backgrounds. This has lead to the rise of web frameworks which have sought to enable the ability to encapsulate data and functionality into components. A video I like on the issues with web development without a framework was created by Jeff Delaney.
This style of data management has seeped into the rest of the frontend application development.
How Other Languages Handle State
Github has a curated list of javascript state management solutions.
Flutter State Management Options
Flutter has a list of official state management solutions. Some of them are even the same as the ones for the javascript frameworks like Mobx and Redux.