While I don't use Redux anymore, one point in the article really resonated with me: having a single source of truth for the entire app state enables you to "run an entire functional application without any visual components having been built whatsoever".
This decoupling of state (and its reducers/actions) from view is a powerful architecutral pattern that I learned from Redux, and I've built every React application (or component) following it. It's separation of concerns at its best, where the heart of the app is about designing data structures and interfaces (as in API), with reusable, composable, and unit-testable states and actions. The UI then becomes just another consumer of the API, so one can develop/rebuild/extend the view as its own separate layer of concern. Looking back, it's hard to believe I was able to keep things organized any other way.
Do you store all UI state in redux as well as all 'resource state'? Phrased as an example... If you store a JSON object that can be edited in your store do you also store a Boolean value for whether the dialog is open that can be used for editing that JSON object?
I agree with that logic, I think I've encountered every one of those cases.
That makes me see that there isn't a "god" object like the article calls it, that holds all of the app state. There's the root state shared throughout the app, and then each page or component can have its own encapsulated state.
Ideally I like to also keep page- or component-specific state+actions decoupled from their views, functional and testable independently - but often I start/keep them in the component class (and maybe soon hooks).
You can also apply the command pattern in some cases and store the undo redo state globally.this at the global store can be generic and the previous specific state will be part of the saved commands. (More applicable to SPAs).
Hmm, typically, I do store "UI state" (or parts of it) in the top app state if that UI state is shared among pages/routes. In your example, if I want that dialog state to be "persistent" - say, the user goes to another route then comes back, if the dialog state should be kept. Otherwise, I store them in the route component's state, which gets created anew every time.
But your question makes me think, if I store any UI state in the app state, have I really decoupled state and view? I'd say yes - since I'd be able to build and test UI state and actions, independent from the view.
Well, at least theoretically, the way I organize state management allows me to pull in "slices" of app state/actions (or even moved into shared libs/modules), to compose a smaller subset for an API or CLI. So the latter can choose to not include any of the UI-related state.
In practice I haven't used it so much, but I like the idea of treating the UI as just another render target / consumer of app state/actions. It enables "remote control" of the app logic, makes testing simpler, and allows reuse for various interfaces like CLI, API, maybe React Native too.
I've been playing around switching web-apps and other user programs between devices on a single-ususer facing kubernetes system. Part of that relies on all state being sent to the server for distribution if a device switch happens.
I also have played around with a wrapper functions and that can bubble any callback/hook up to the data for further processing. The client no longer worries about sending actions. The server spys on client actions and performs actions on their behalf.
Hi, I have exactly the same conclusion as you - you can check my demo todo app - where the UI is an extension to the app. I'm having React and Mustache renders to demonstrate how the view is totally decoupled from the app logic. It have SSR, both for React and Mustache, Service worker for offline usage. Redux for state management. I'm using typescript.
That diagram is wonderful, every part of it makes sense. I also liked how you describe the "lifecycle" step by step. In a way, it made me realize how the Redux pattern fits in with an evolution of MVC.
I think I'm similar to you, in that I've been developing my own solution to manage the whole app lifecycle in a way that makes sense to me, with a library of (mostly) my own modules so I can reuse it across all apps I build.
At the same time, there's value in following "community standards", generic libraries and patterns that most people are familiar with. So, I'm a bit torn on creating my own patterns/utilties versus adapting existing ones that everyone's using.
Thank you so much for checking it out. I'm so happy that diagram makes sense to you.
One of my favorite talks is from Robert Martin, the first link on the bottom of the about.md - when he explains the history of MVC, I realised that the original idea for MVC is exactly what Redux is. But in the years people changed the meaning of MVC and that's why now it seems different. For me, Redux is 1:1 as M from original MVC docs from the 70s.
I'm also torn on using "standards" vs my own implementation. I feel kinda like an outcast, using my own "framework".
Side joke:
With hooks and functional components, the React community is moving in our direction. I cannot wait for the next logical conclusion - Lets move the hooks out of the components :)
I would like to see some of your code, if you like to share it, please send me an email: alex.tzvetanov at gmail com
Thank you again for spending time on my code and thanks for the feedback!
This decoupling of state (and its reducers/actions) from view is a powerful architecutral pattern that I learned from Redux, and I've built every React application (or component) following it. It's separation of concerns at its best, where the heart of the app is about designing data structures and interfaces (as in API), with reusable, composable, and unit-testable states and actions. The UI then becomes just another consumer of the API, so one can develop/rebuild/extend the view as its own separate layer of concern. Looking back, it's hard to believe I was able to keep things organized any other way.