Triggering action in bad store practice?

Question

It is suggested that stores must handle events triggered by actions and emit a change in view controllers.

Is it good for them to run actions, for example, in a request callback or directly in a registered store callback.

For instance:

AppDispatcher.register(function(payload) { switch(payload.action.actionType) { case Constants.PAGE_CHANGED: ActionCreator.fetchNewData(); break; case Constants.FETCH_DATA: // save data Store.emitChange(); break; } }); 

Is such code “correct” in the Flux architecture?

Thanks!

====== UPDATE BASED ON COMMENT:

This is not a question, “I need to do this. How do I do this?”, But “If it will be a way to do something.” And I think the answer ... is your choice.

Some useful links have been added in the comments. Thank you for that.

My understanding of things is this:

In the Flux architecture, views should be the only ones that trigger actions. Put asynchronous requests in your action creator, and the callback should start a new action.

When Flux steps are not performed, the store can also handle asynchronous requests, but make sure that the callback does not process the data directly, but instead triggers another action. See Bill Fisher's Answer for this.

In any case, as Ben Alpert said, you can create several actions for the user action (for example: REQUEST_START, REQUEST_SUCCESS, REQUEST_ERROR), which allows you to connect to the various stages of your request.

Any updates on this are welcome.

Answer 1

Short answer: Yes - launching an action in a store is bad practice.

And in response to the current version of the dispatcher, I don’t even think that you can send a new action when sending, as well as when a new action is called in the repository.

I’m just a little boyish scout when it comes to the flux pattern , but I pushed production response projects, where we decided to give him full access and use extreme activities, shops and events regarding the flow.

I think you should never force stores to trigger new actions, as this can lead to very strange behavior when projects begin to develop. It’s true that this doesn’t really “break” the thinking of the data stream, because you still (should) process the response as usual, and then everything is fine. But if you really need it, I would rather name what fetchNewData() calls directly inside the first action.