Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Flux Dispatcher - View actions vs. Server Actions

Tags:

reactjs-flux

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.

like image 452
user413945 Avatar asked Oct 02 '14 04:10

user413945


People also ask

What passes data and action to dispatcher?

The dispatcher method allows us to trigger a dispatch to the store and include a payload of data, which we call an action. It is an action creator or helper methods that pass the data to the dispatcher.

What is likely to happen in Reactjs flux when a dispatch is triggered and the store gets updated?

Stores get updated because they have a callback that is registered using the dispatcher. Node's event emitter is used to update the store and broadcast the update to view. The view never directly updates the application state. It is updated because of the changes to the store.

Which of the building block of flux architecture is responsible to receive actions and broadcast payload to the register callback?

In a typical Flux architecture, you will find the following components. Dispatcher - Receives these Actions and broadcast payloads to registered callbacks. Stores - Act as containers for application state & logic. The real work in the application is done in the Stores.

What Characterises flux dispatcher in react?

The dispatcher is a singleton, and operates as the central hub of data flow in a Flux application. It is essentially a registry of callbacks, and can invoke these callbacks in order. Each store registers a callback with the dispatcher.


1 Answers

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.

like image 56
fisherwebdev Avatar answered Oct 05 '22 06:10

fisherwebdev