Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Redux is a sloppy implementation of CQRS. The value for the feature is the same as any event sourced system: being able to observe what's firing and how the internalized state system is applying state transformations over time.
This behavior is useful in complex runtime scenarios that may have resolvers whose implementation is conditional, or unexpected sources of incoming data. In those situations, debugging unexpected data results is usually a black box, so without the ability to walk the before and after states of the transformation sequence, you wouldn't be able to easily trace the source of an unexpected mutation. Like most debug utilities, it makes running experiments easier.
In most distributed CQRS+event sourcing systems, we would do something like this as a facet of audit trails and pre-snapshot simulacra.
So, redux is a bit of a sore spot with me. We've been doing this sort of thing in distributed backend systems for 15 years and there's a truism that comes up a lot:
"You probably don't need CQRS"
The seminal argument on the subject:
Given that, I don't think redux (and event sourcing/CQRS by extension) is actually a good tool for front end. I build massive applications and still prefer feature-specific services that then aggregate into application-level services for message propagation.
Even in the backend distributed portions, we prefer patterns like actor-model for scale and consistency:
Dacexi24When there are only 2 pages on Google you know you're in serious shit.
practiseSafeHex21Fixing a parents iPhone, episode 1. Problem: "Whatsapp is gone off my phone" Debugging: Me: *unlocks phone...
nachocode7When you talk to other devs about what their code did. I also relate myself to this.