IMPORTANT TIPS AND MOUTH-WATERING RECIPES
State management is in a bad state: actions, reducers, stores, middleware, this hook, that hook — it’s all so unnecessarily complicated, and it slows application development. Why is it necessary to jump through so many hoops just to implement simple functionality? What exactly are we trying to accomplish, anyway?
In this article, we’ll uncover the architectural ambiguity that lead to these unnecessarily complicated “state management” solutions. Clarifying this ambiguity leads to a much simpler and more natural solution — a solution that empowers us to develop higher-quality applications faster.
To fix any problem, we first need to understand it. To understand state management, we need to look at the view framework architecture. State management is one of only two parts in the view framework architecture:
Haven’t seen this diagram before? Me neither, but there’s asimilar diagramin a flux presentation with the note:. In that presentation, the box is labeled “data” instead of “state management”. And therein lies the problem —what exactly is that box?After some pondering, I came to realize:
The box represents theof application logic and functionality.
Perhaps you already know this, perhaps some part of me already knew this — but bringing this to the conscious, putting it on paper, changes something. It provides a much clearer picture of the architecture: