Redux is a library which implements an architecture somewhat similar to event sourcing, but with a…
Eric Elliott

Redux is a library which implements an architecture inspired by event sourcing

Redux library was never inspired by Event Sourcing because the author already told me that he didn't know Event Sourcing when he created it.

It was inspired on something (flux) that may or may not have been directly based on Event Sourcing. Considering the way things are, there's evidence that none of them were based on it (maybe just "inspired" as you say, which means nothing).

Sometimes these things take on a life of their own beyond what the author envisioned. That’s exactly what happened here.

Do you think it's a good thing abstracting useful information in libraries instead of standing on the shoulders of giants and building on top of already known concepts in a way that libraries become unnecessary?

I can bet you this whole thing will just "evolve back" to Event Sourcing, for the lack of a better definition.

… but with a functional programming twist

What is exactly the twist that improves it over Event Sourcing? Are you saying that Event Sourcing can't be functional? It uses command and events, which is fundamentally functional, but can also be expressed in other paradigms. The good thing about talking in the architecture level is that many solutions doesn't need to be tightly coupled to a paradigm, which is a benefit on its own.

…but it implements essentially the same pattern with a small adaptation: the store is an observable.

Comparing with Event Sourcing, from what I understand, the Redux store is something between Event Store or View Projections and the Reducers are Sagas. Since you are more inside the context of ngrx/store, what is the actual benefit of using the store as an observable in the context of improving the "Redux architecture"?

Using observables seems to be just a workaround instead of just replaying the Event Store to build View Projections (each operation being decoupled from each other).

There is some related discussion in the redux repository that might be interesting.

Perhaps Dan Abramov did not intend to inspire a change in the way we think about state management architecture when he built his library, but that is exactly what he did, even though many of us have written lots of event sourcing implementations before. Prior to Redux, I’d never done it with reducers.

As new developers enter the front-end they will also go through the same path. There is a change in the way people think, now it's time to point them to what it really is.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.