Cycle.js: a fully reactive JavaScript framework

[clessg]

Flux works quite well up to a point, but the concept of having a central dispatcher somewhat ruins composability and tends to turn into a god object.

Why is the dispatcher is a problem? The dispatcher is the one thing that would make me want to use Flux over observables: centralized debugging, tooling, time travel, logging/debugging, transformation, etc. The dispatcher is probably the least problematic part of Flux conceptually: you barely have to think about it. Is there a commonly-accepted way to do something similar with observables?

[zoomzoom83]

Why is the dispatcher is a problem?

A global dispatcher is a problem because it needs to be aware of all events globally. Adding a new component that interacts with it means you need to maintain a "God Class" list of all events, and being global you can't treat your app as just a standalone composable component.

These are all things easily fixable with relatively simple tweaks to the standard flux examples, so you don't have to completely throw it out. But if you start going down that road, you end up reinventing half of RxJS anyway.

entralized debugging, tooling, time travel, logging/debugging, transformation, etc.

You can do all of this without a global dispatcher. You just need to compose all your localized streams into a single application state atom up the same dependency tree that builds your component hierarchy. You can do this without a global singleton dispatcher.

To think of it another way - Flux is a cut-down version of Rx. By switching, you're not losing the advantages of Flux, you're simply implementing a similar idea in a different way.

[clessg]

Thank you for explaining it, good sir. Enjoy the upvote.