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]
[0] https://martinfowler.com/bliki/AnemicDomainModel.html
[1] https://martinfowler.com/eaaDev/EventSourcing.html