Looking at that code block I know immediately that there are only 3 ways that the state can change and what happens during each transition.
This code is easy to unit test and verify that it is correct meaning that as long as the frontend components dispatch the right actions the store will contain the correct state.
Since the UI should just be a function of the store this means that there is no guess work when it comes to reasoning about what the rendered view will look like after each action.
I'm working on porting an angular SPA to react/redux. While the amount of code increased the whole thing is a lot easier to understand. The angular version had a lot of race conditions that I could never fix.
But is the UI just a function of the store? (I guess "store" in this context means the model data that is persisted on the server -- sorry if I'm getting the terminology wrong.)
For example, something like selection typically isn't part of the model. (Users don't expect to undo a selection in an editor.) That means components will need to manage that kind of transient state internally, and the whole "UI is just a function" paradigm kind of breaks down.
The "store" is purely data that is on the client. What data you put in the store is up to you. It may be a mixture of domain data from the server ("what items do I have in cache"), application-specific data ("the current selected item is #42"), and UI state ("there is a modal that is visible, of type ItemEditor"). It's certainly possible to put every single bit of data in your app into Redux, but there are definitely reasons to want to keep some of it in local component state. The classic example is "a dropdown is open" - other components probably wouldn't care about that, and it's not something you'd want to persist or toggle during time-traveling. It's up to you as a developer to decide what state should live where.
The UI can be purely a function of the store state, or not; whichever makes more sense in your project. I find it useful to use transient component state (ie. setState) also, for things like you mention - selecting something or keeping track of the "isOpen" state of a dropdown. Any state which does not need to live longer than the UI itself.
> the whole "UI is just a function" paradigm kind of breaks down.
Not really, it just goes from "UI is a function of the store state" to "UI is a function of the store state AND the component's internal transient state". Since internal state should only be modified by the component itself calling setState, this doesn't really add much complexity - in fact it usually reduces app complexity by obviating the need for a complicated global state structure for storing eg. the open state of every possible dropdown on the page.
Looking at that code block I know immediately that there are only 3 ways that the state can change and what happens during each transition.
This code is easy to unit test and verify that it is correct meaning that as long as the frontend components dispatch the right actions the store will contain the correct state.
Since the UI should just be a function of the store this means that there is no guess work when it comes to reasoning about what the rendered view will look like after each action.
I'm working on porting an angular SPA to react/redux. While the amount of code increased the whole thing is a lot easier to understand. The angular version had a lot of race conditions that I could never fix.