1

I'm familiarising myself with both Flux architecture, and Reflux - the simpler version, without a dispatcher - for use with ReactJS.

In full Flux, it sounds like actions have (or at least, can be made to have) a definite and non-trivial purpose: they can be used to update external services (eg. save data back to the server via an API), as described in this question: Should flux stores, or actions (or both) touch external services?

However, in Reflux, the actions are definitely just dumb message parsers. So my question is, what purpose do they serve? Why have them at all? What bad things would happen if your Views/Components just called methods on your store directly?

I'm about to convert my little app from Flux to Reflux, and it looks like I'll be moving all the logic currently in my actions over to the store. It seems to me like the actions in Reflux do nothing other than act as a useless middleman between the component and the store. What am I missing?

Community
  • 1
  • 1
joshua.paling
  • 13,762
  • 4
  • 45
  • 60
  • "What bad things would happen if your Views/Components just called methods on your store directly?" --- you wouldn't have a unidirectional cycle. So you wouldn't have Flux at first place. What you're missing is the action handler may not change a store at all. Or may not only change a store. – zerkms Jun 01 '15 at 01:55
  • "do nothing other than act as a useless middleman between the component and the store" --- they do: they untie your presentation from data. – zerkms Jun 01 '15 at 01:57
  • Makes sense. Add that as an answer and I'm happy to accept. – joshua.paling Jun 01 '15 at 02:45
  • That's too few to be a real answer and I'm too lazy to put a proper one. Let's see if someone more enthusiastic than me comes here ;-) – zerkms Jun 01 '15 at 02:49
  • For anyone else who reads this, I should add that multiple stores can also listen to the same action - so that's another reason to have actions separate. – joshua.paling Jun 01 '15 at 12:29

1 Answers1

2

Besides the ability to listen for an action in any number of stores as pointed out in the OP comments:

Reflux actions can also touch APIs and such, by placing it in the preEmit action hook for example. Typically you'd create an async action, add some async stuff in the preEmit hook, and then call the "completed" or "failed" sub-actions when the async work is done (or has failed). You can also do sync work in the preEmit hook of course. Logging comes to mind.

It's also fully possible to listen to an action in a store and perform the async work in the store, then call .completed or .failed from there, but I think the consensus that has formed is that stores shouldn't do that work, stores should just react to changing data, not perform business logic.

Async actions also work as promises. Of course you could implement your stores to do that as well, but I'd argue that that's a lot of responsibilities for a data store.

Hannes Johansson
  • 1,794
  • 2
  • 15
  • 28