Dispatcher promise only resolves after this.emit('change')

[gilbox]

I noticed that if the store doesn't this.emit('change'), then the dispatcher never resolves it's promise.

   Dispatcher.dispatch('someAction', data).then(function() {
     console.log('dispatch resolved!');  // only fires if we emit change
   });

Is this intentional? The only reason I can think to architect it this way is to allow the Store to do some asynchronous work, which I thought is supposed to be the domain of the Action Creators?

I'd like a store to be allowed to mutate it's own data without emitting a change event. Am I crazy?

BTW, I'm not using React so feel free to ridicule me :smiley_cat:

Also, I'm very new to this Flux stuff so if I'm totally missing the point please do let me know.

[darcyadams]

Sorry for the slow response...

The only reason I can think to architect it this way is to allow the Store to do some asynchronous work, which I thought is supposed to be the domain of the Action Creators?

That's up the developer. I prefer to put async work in the actions, but I don't see why the server interactions couldn't live inside of the stores (much like a backbone model or collection).

I'd like a store to be allowed to mutate it's own data without emitting a change event

A store can mutate it's own data, just not through the action dispatch mechanism. (eg you could mutate data in the getState method).

Perhaps you could elaborate on why you want to mutate data without a change event? This may very well be a difference in philosophy between React and other frameworks. In React, you always want to trigger a view render when any state data changes since there is little to no performance penalty for triggering a 'render. You always want to know about every change. In an MVC like Backbone, often I'd find myself using silent: true when setting data in order to wait and more efficiently update the DOM after future change events fire.

[gilbox]

Perhaps you could elaborate on why you want to mutate data without a change event? This may very well be a difference in philosophy between React and other frameworks. In React, you always want to trigger a view render when any state data changes since there is little to no performance penalty for triggering a 'render.

Thank you! This pretty much answers my question. But to answer your question as to why I want to mutate data without changing state, there are two reasons:

• The way that I'm trying to use delorean with angular there is rarely the need to emit a change event (because the Store's data is bound directly to the view), although in my demo app (plunker) there is no real penalty for doing so.
• My Store.initFacesSuccess() method responds to the initFacesSuccess action, but doesn't actually make any mutations that require immediate update.

Also, in retrospect I realize that I don't really need to wait for the Dispatcher.dispatch() call to resolve it's promise if I know that my Store is completely synchronous...

Re: my store being bound to the view: I think this is un-Fluxy (?)... I'm following the self-imposed rule that the view will never directly mutate Store data. In this scenario, there are definitely times when I will want to react to store change events, the most obvious use case being when the view needs to clone a store property to mutate locally (although I haven't yet explored this use case).