> Really... how data flows through your program is actually a separate graph structure, and how HTML elements are organized in your program is another separate graph structure we try to graft into the first one and that creates a mess.
My team migrated away from Redux and for over a year I’ve been unable to pinpoint why I’ve been longing for it again. This has hit the nail on the head for me. Redux (and other “global” state management solutions) allowed me to decouple the data graph from the UI graph. When a UI event is triggered, an action is dispatched and then the data graph takes over. This makes the UI graph extremely simple - render UI and dispatch actions - but these days we’re mixing state with business logic, event handling, API calls, rendering UI, styling, etc. This is very much a problem of our own making that could be solved by a different architecture, but yeah… thanks for clarifying this feeling for me.
because any component that uses that state management solution becomes coupled to that global state. So let's say I want to use such a component in context of a completely different "global" state, then I can't do that anymore. Global state only saves you from prop drilling where you have to insert props into every parent element above the relevant element.
Believe it or not Jquery + html actually did the seperation of data flow and GUI much better than react.
The question is, how do I get re-useable GUI widgets that are decoupled from state all together such that every widget on my SPA can be reused anywhere on different global contexts and even on different apps. React does NOT solve this problem.
My team migrated away from Redux and for over a year I’ve been unable to pinpoint why I’ve been longing for it again. This has hit the nail on the head for me. Redux (and other “global” state management solutions) allowed me to decouple the data graph from the UI graph. When a UI event is triggered, an action is dispatched and then the data graph takes over. This makes the UI graph extremely simple - render UI and dispatch actions - but these days we’re mixing state with business logic, event handling, API calls, rendering UI, styling, etc. This is very much a problem of our own making that could be solved by a different architecture, but yeah… thanks for clarifying this feeling for me.