The problem with redux is actually the dev-tools (and the ecosystem that spawned from the middleware). the newbies get wowed by "time travel debugging" and want to copy/paste there way to the $$$profit.
Redux takes a simple concept, and turned it into something thats really hard to apply to the projects these people are writing; by reinventing words into a propriety language.... No one talks about about there state as a function of "reducers". And when they think they have their head around "actions" they realise that no, its not a 1-to-1 relationship with what the user is doing.
If redux didnt try and re-invent event-sourcing with its own "idomatic TAO way", it could of leveraged off the plethora of well written documentation on the subject.
Instead, Dan, thought he could improve event sourcing and make it palatable for the masses by
-replacing "events" with "actions" [1]
-making the state an anemic domain model[0]
-persisting snapshots instead of an event log then adding on congnitive load by implementing a diffing algorithm for UI updates which requires specialised knowledge. [1]
The domain model is technically not anemic. It just uses more functional patterns. Using lenses/selectors to manipulate state instead of using OOP principles, as is common in FP languages. In the same groups talking about reducing an event log is fairly common too. Possibly more common would have been to call it "fold" I guess, but that's essentially a synonym.
As to your other point, you're right, and it is somewhat of an issue: Redux does work better when it's thought of as event sourcing. And it can (and IMO should) be used as one. When actions are nearly 1:1 with what is happening in the system, and you're simply doing a "fold" on the event log to then project it to a stateless UI, it works beautifully.
Another red flag on redux: recommended practice--query JSON over HTTP (likely backed by an RDBMS), renormalize the hierarchical data, and then reshape the renormalized data before passing to components.
Right?! and redux is a baby-monster comparing to Relay that demands developer to actually modify the server's graphQL API in order to comply with the odd requirements.
Redux takes a simple concept, and turned it into something thats really hard to apply to the projects these people are writing; by reinventing words into a propriety language.... No one talks about about there state as a function of "reducers". And when they think they have their head around "actions" they realise that no, its not a 1-to-1 relationship with what the user is doing.
If redux didnt try and re-invent event-sourcing with its own "idomatic TAO way", it could of leveraged off the plethora of well written documentation on the subject.
Instead, Dan, thought he could improve event sourcing and make it palatable for the masses by -replacing "events" with "actions" [1] -making the state an anemic domain model[0] -persisting snapshots instead of an event log then adding on congnitive load by implementing a diffing algorithm for UI updates which requires specialised knowledge. [1]
[0] https://martinfowler.com/bliki/AnemicDomainModel.html
[1] https://martinfowler.com/eaaDev/EventSourcing.html