To all React developers out there:
have you ever used the "so famous" Redux Time Machine Debugger capabilities?

Every now and then I see articles praising that as "one of the greatest things in Redux", but I either didn't understand the feature enough to see usage, or my applications are "way too CRUD"(?) to warrant time-traveling debugging.

Please, someone enlighten me :)

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.

@SortOfTested aha! thanks for that! really clarified things up, it seems I'm just working on simpler stuff then :)

@igorsantos07
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:

http://udidahan.com/2011/04/...

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:

https://doc.akka.io/docs/akka/...