> separation of "what happened" from "how the state is updated" is absolutely intentional
In most projects I've worked on using Redux or Redux-style patterns (which, I'll admit is not a large number), keeping the separation didn't improve things, instead it added to more "fiddliness" and yo-yoing between files in the editor/IDE - this is especially the case when a project is iterating through changing project-requirements, especially for trivial actions/reducers. This only applies to cases where actions had a 1:1 mapping to reducers - and the bundled funcs were strictly pure-functions too, of course.
But I stress that I'm not a Redux expert (blame my lack of experience) so I appreciate that I almost certainly have done something wrong, so I'd love to be able to have a Redux expert on-call who I could just ping on Slack and pose a very domain-specific question to and ask "what is the Redux-way(TM) of doing this?" instead of having to try to go through the very abstractly written (often past the point of comprehension) pages of official documentation, blog articles and the like and hope I'm doing things correctly (especially in non-JavaScript environments).
----
Obviously the biggest barrier to the adoption of the Redux-pattern in non-JS environments is other languages' syntactical hostility to immutable objects, especially immutable object construction. In OOP-family languages like C#, Java, etc it really is a significant burden to have to both define primary constructors and the logic for reconstituting an entirely new state-graph for actions that only make 1 small, tiny deeply-nested change.... across multiple deeply-nested objects. The next major burden is the extra workload involved to change all of the above when project-requirements change regularly. There are also associated problems with having to normalize the state-graph and how to handle back-references (as true immutable objects cannot have back-references to parent objects unless you add another layer of wrappers over the state graph, and now you see the problem...!).
Also, remember that statically-typed languages are not going to get anything like JavaScript's spread-operator for a long, long time.
It sounds horrible (if not being complete heresy), but having state exposed as read-only to components/consumers, while allowing state mutation in-place by actions, does result in a drastic simplification of logic (I can't really call them "reducers" at this point), while you do lose the "free" Undo/Redo bonus you gain much faster performance. The important thing is the strictly one-way flow of data within the application, which is preserved, as is determinism: replaying the same actions from the same initial state will still result in the same end result state. (I'm not strongly advocating for the above, I'm just saying that to non-Redux-experts like myself, compromises can and do have perceivable value; after-all, we aren't all working on the official Facebook mobile app).
In most projects I've worked on using Redux or Redux-style patterns (which, I'll admit is not a large number), keeping the separation didn't improve things, instead it added to more "fiddliness" and yo-yoing between files in the editor/IDE - this is especially the case when a project is iterating through changing project-requirements, especially for trivial actions/reducers. This only applies to cases where actions had a 1:1 mapping to reducers - and the bundled funcs were strictly pure-functions too, of course.
But I stress that I'm not a Redux expert (blame my lack of experience) so I appreciate that I almost certainly have done something wrong, so I'd love to be able to have a Redux expert on-call who I could just ping on Slack and pose a very domain-specific question to and ask "what is the Redux-way(TM) of doing this?" instead of having to try to go through the very abstractly written (often past the point of comprehension) pages of official documentation, blog articles and the like and hope I'm doing things correctly (especially in non-JavaScript environments).
----
Obviously the biggest barrier to the adoption of the Redux-pattern in non-JS environments is other languages' syntactical hostility to immutable objects, especially immutable object construction. In OOP-family languages like C#, Java, etc it really is a significant burden to have to both define primary constructors and the logic for reconstituting an entirely new state-graph for actions that only make 1 small, tiny deeply-nested change.... across multiple deeply-nested objects. The next major burden is the extra workload involved to change all of the above when project-requirements change regularly. There are also associated problems with having to normalize the state-graph and how to handle back-references (as true immutable objects cannot have back-references to parent objects unless you add another layer of wrappers over the state graph, and now you see the problem...!).
Also, remember that statically-typed languages are not going to get anything like JavaScript's spread-operator for a long, long time.
It sounds horrible (if not being complete heresy), but having state exposed as read-only to components/consumers, while allowing state mutation in-place by actions, does result in a drastic simplification of logic (I can't really call them "reducers" at this point), while you do lose the "free" Undo/Redo bonus you gain much faster performance. The important thing is the strictly one-way flow of data within the application, which is preserved, as is determinism: replaying the same actions from the same initial state will still result in the same end result state. (I'm not strongly advocating for the above, I'm just saying that to non-Redux-experts like myself, compromises can and do have perceivable value; after-all, we aren't all working on the official Facebook mobile app).