Flux Dispatcher - View actions vs. Server Actions

Question

Is there any reason, other than semantics, to create different dispatch methods for view and server actions? All tutorials and examples I’ve seen (most notably this) ignore the source constant entirely when listening to dispatched payloads in favor of switching on the payload's action type.

I suppose there is a reason why this pattern is pervasive in flux examples, but I have yet to see a concrete example as to why this is useful. Presumably one could add an additional if or switch on the payload source to determine whether to act in stores, but no examples I've seen consider this constant at all. Any thoughts on this would be much appreciated.

Sambar

Answer 1

Yes, this was cruft/cargo-culting that came over from a particular Flux project at Facebook, but there is no real reason to do this. If you do need to differentiate between server and view actions, you can just give them different types, or have another property of the action itself to help differentiate them.

When I get time, I plan to rewrite all the examples and documentation to reflect this.

Fountain

Is wrapping the action into a payload an advisable step? Or should the dispatcher just pass the action "as is"? – Neckpiece

I think passing the action as-is cleans up the code and is preferable. The payload and the action can be synonymous. Note that the Dispatcher is a generic utility that can be used for things other than Flux, hence the term "payload". – Fountain