reflux / refluxjs

A simple library for uni-directional dataflow application architecture with React extensions inspired by Flux
BSD 3-Clause "New" or "Revised" License
5.36k stars 330 forks source link

Reflux without actions listening #522

Closed sergeysibara closed 7 years ago

sergeysibara commented 7 years ago

Sorry for the duplicate, but I did not receive a review.

In my library I refused from action listening. You can also do it in Reflux.

I implemented your Counter example with using my library and with using Reflux without actions listening: UIStates Counter Reflux Counter without actions listening

What do you think about this approach?

BryanGrezeszak commented 7 years ago

Sorry if I missed something from earlier. I don't see any issues from you previously.

Technically making changes to stores without actions works. There's no reason it wouldn't. It's just that it's not fluxy :)

In flux-ish type systems the general idea is that with that 1 way flow it's easier to keep track of everything happening, easier to edit old code, easier to add new code.

Of course, in tiny examples that just seems like extra code for no reason. But in large projects that's where it shines.

Let's say you have a button labeled "increment". Every time it gets pressed you want the count value in StoreA to go up.

Technically, you can just call a function in StoreA that does that. Bypass building actions, right?

But what situation did we just create? If that's the pattern we follow, now for every program change that happens the place that initiates the change needs to know everywhere that it needs to go, AND everywhere it needs to go needs to have the ability to accept that change. Both sides need to be aware.

With more and more possible changes in the program, the complexity of the program therefore increases exponentially.

With actions the item dispatching the action does NOT have to know anything about the changes it's making, or where they're happening.

You want to add another store later that also has something change every time a certain thing happens? Cool, instead of having to go find every place in the program where that change happens and making it also change something in that new store...you don't have to do that. Just listen for the action. The new store takes care of itself modularly, leading to a linear increase in program complexity as the program grows, rather than exponential increase.

Basically the entire point of flux is to not require a component to know everywhere that an action will affect program state, therefore making the program far more modular, easier to add to, and easier to modify.