0

I am trying to wrap my head around Flux, and I actually got a contrived example working, but I'm a bit confused about the event flow. Let's say I define an action called TestAction. My view has an onClick that emits that event;

Dispatcher.dispatch(new TestAction(this.state.currentValue));

Great, it flows down to the store. So far, so good, I get it.

Now, my store does whatever magic it does, talks to servers, etc. and updates itself. Then, for some reason, all examples show the store doing something along these lines;

Dispatcher.register((action: Action) => {
  if (action instanceof TestAction) {
    var text = (<TestAction>action).text;
    console.log('Store got: ', text);
    this._text = text + '_';
    this.emit(TestStore.TEST_EVENT, this._text);
  }
});

So I guess my question is, why is it firing the very same event? Is it specifically for the dispatcher to handle waitFor? Does it inherently understand what it means for the same event to come back?

XeroxDucati
  • 5,130
  • 2
  • 37
  • 66
  • Could you clarify what you mean by 'why is it firing the very same event'? Which event are you talking about? – Prashant Abhishek Sep 18 '15 at 16:23
  • I guess it's more a semantic difference I'm asking about. I have a TestAction, and then a TEST_EVENT. Is it just a naming difference where Action is from view -> store and store raises events back out? I don't understand the data flow correctly i guess. – XeroxDucati Sep 18 '15 at 18:35
  • ok. I will explain the data flow in answer. – Prashant Abhishek Sep 18 '15 at 18:37
  • Take a look at http://stackoverflow.com/questions/32335680/react-with-flux-is-this-the-dogmatic-pattern-or-are-there-equal-better-options/32358138#32358138 – J. Mark Stevens Sep 18 '15 at 19:36

1 Answers1

1

Views which are React components issue an action whenever an event (like click) happens.

These actions then use utils/apis to fetch/push data to server and then use this fetched/pushed data to send as payload in a through a dispatcher.

Dispatcher is a central mechanism to notify multiple stores about an update, the update being the payload being dispatched along with a particular action type.

Stores register for particular type of action types. And whenever the dispatcher sends an update about that action type, the stores update themselves with that data and they emit a change event, saying that state of store has changed.

Views subscribe to these stores, and whenever the stores emit a change event, views update their stores and re-render themselves. This is one whole circle of data flow. Again when certain event happens on view the loop starts.

Uni-directional data Flow-

Views -> Action -> Dispatcher -> Stores -> Views

This is a good article for further details- https://medium.com/brigade-engineering/what-is-the-flux-application-architecture-b57ebca85b9e

Prashant Abhishek
  • 116
  • 5
  • So this mostly makes sense, except I'm a bit confused about utils/apis -- are you saying the Action should be calling any server-side logic? For example, lets say I have a dumb object store on the server, that stores a generic JSON object -- I assumed the Store constructor would do a GET to grab that object, and when it sees actions, would update to the server and emit the updated JSON.. Are you saying that should happen in Action somehow? – XeroxDucati Sep 18 '15 at 19:33
  • @XeroxDucati Yes, action should call apis, get data and dispatch it. And Stores should update themselves using that dispatch, stores should not do a GET, you probably got the point. – Prashant Abhishek Sep 18 '15 at 19:52