Thanks for the response! It was super interesting to read other viewpoints on the matter!
One quick note is that the business logic in applications pertaining to data mapping etc. from the store to the React layer is still happening in selectors, this approach impacts the actions side of things more (whilst providing some useful base selectors to work with).
The actions themselves still do not contain any real logic. It falls to sagas (triggered by more traditional actions) to call the relevant pure functions to perform the business logic and then subsequently dispatch the subsequent mapped functionality to the relevant reducers.
Therefore there’s still the idea of a ‘single action’ that is dispatched when an update is particularly complex. This action will then subsequently call one or more of the automated actions, as required. However, it does impact the ability to redo/undo easily with redux as, as you’ve stated, the functionality driving all of the reducer updates for a given action no longer occur as part of one singular action. It is no longer a singular action from a redux perspective!
Shifting the functionality from the reducers to the saga layer doesn’t impact the purity of such functions or their testability though, and has the advantage of collecting all of the functionality relevant to an action into one easy to reference place. It’s a tradeoff of raw redux functionality versus developer convenience.
As for whether this remaining ‘reducer layer’ even still needs to be redux though? In theory it doesn’t have to be. Although the loss of useful tools such as redux-dev-tools, redux-sagas, react-redux etc. don’t make it a particularly tantalising prospect!