Only one action can be dispatched at a time

[binarymuse]

Only one action can be dispatched at a time

[BinaryMuse]

That's a great question, @jsilvestre.

Flux is really all about managing the flow of data in the system—ensuring that store state changes only take place in response to an action dispatch. Preventing "cascading updates" is one of the ways flux helps prevent confusing data flows; what this means is you can't dispatch a second action from inside another action handler. It's the thick red line in the top of this diagram that should be prevented:

Fluxxor specifically does not prevent side-by-side dispatches on the same tick of the event loop (it used to, but this changed in version 1.2.0). Since XHR and websocket handlers run asynchronously, you shouldn't run into issues dispatching actions from inside them.

Please feel free to re-open this issue if you have more questions or something doesn't appear to be working correctly.

[jsilvestre]

Thank you very much for the detailed answer. I understood better what was going on after reading http://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html and understanding why the "dispatching loop" in http://facebook.github.io/react/img/blog/flux-diagram.png should be synchronous.

Now I fully understand how Flux is supposed to work and the exact differences between Flux and MVC :)

Thanks agains.

[arathunku]

Hi,

I was wondering, is there something against dispatching multiple things in one action? I'm trying out Fluxxor (great work!) and flux and I'd like to notify RequestsStore about ongoing requests. I've something like:

var GridListConstants = require('../constants/GridListConstants');
var RequestsContants = require('../constants/RequestsConstants');

var Promise = require("bluebird");
var Users = require('../api/Users');

module.exports = {
  selectElement: function(element) {
    this.dispatch(GridListConstants.SELECT_ELEMENT_LOAD, element);
    this.dispatch(RequestsContants.REQUEST_LOAD, element);

    Users.find(element ? element.id : null).then(function(payload) {
      this.dispatch(GridListConstants.SELECT_ELEMENT_SUCCESS, payload);
    }.bind(this), function(payload) {
      this.dispatch(GridListConstants.SELECT_ELEMENT_ERROR, payload);
    }.bind(this)).timeout(3000).catch(Promise.TimeoutError, function(){
      // request cancelled
    }).finally(function(){
      this.dispatch(RequestsContants.REQUEST_FINISH);
    }.bind(this))
  }
};

Is there any better way? It seems like there are not many examples

[BinaryMuse]

@arathunku, dispatching multiple side-by-side actions, or dispatching additional actions in response to an asynchronous event, is fine. You could send the REQUEST_LOAD and REQUEST_FINISH actions, as in your example, or you could tell the RequestStore (or whatever it is) to watch for the individual *_LOAD, *_SUCCESS, and *_ERROR actions. I think either approach is valid depending on how many different actions you have and how you want to manage them.

Another thought is to push the dispatching of the REQUEST_LOAD and REQUEST_FINISH actions into some higher-level communications abstraction, so that any time you make a request or a request finishes those actions are automatically dispatched.

[arathunku]

@BinaryMuse, thank you for response, highly appreciated. I'll go with a wrapper around requests, it will reduce boilerplate needed to handle timeouts, cancelled events etc.

[jawb]

Hi guys, I need some help related to this issue. I have a command OPEN_MODAL, and when some actions are called, namely remove action, I need to do an OPEN_MODAL from store, but Flux prevents dispatching an action ('OPEN_MODAL') while another action ('REMOVE') is being dispatched.
I'm using now a setTimeout which is a lazy dirty solution that I'm not proud of. Please advise what's the solution for this, and what's the best way to go about this kind of dependency between stores and actions ?

[drobtravels]

@jawb Think of the events more as business events that different components can choose how to respond to.. not specific instructions of how to change the view. In your case you should have a single event defined for whatever is triggering this action. Your stores and views can react to this event by opening the modal and removing the data (Remember that multiple stores can be listening to the same event)

[skatou]

According to @BinaryMuse and @jsilvestre, two constraints we need to obey to prevent two actions dispatched at the same time,

1. don't dispatch new action within an action handler;
2. dispatching loop should be synchronous.

I totally agree with 1, but constraint 2 is so strong that prevent me from applying some design decisions.

Before I read this issue I planned to have my Store doing two optional tasks on receiving an action,

1. making XHR calls;
2. persisting store data.

Knowing that dispatching loop should be synchronous, I decided to move XHR calls out of action handler, only after the XHR calls are finished I create an action and make the dispatch call, this is fine since making XHR calls doesn't require much knowledge about the inner structure of Store.

But I am stuck in the data persistent part. I am working with react-native and want to persist data with AsyncStore or through my exposed sqlite module, the persistent works in async way. I can ignore the async callbacks but it leads to inconsistent on failure.

What should be the best practice?