Is there a problem triggering actions from a store?

[jmarkstevens]

I look at actions/listeners as a publish/subscribe pattern and use actions wherever and in series if called for. Some flux implementations seem to have a problem calling an action from within another action. I have not had any issues doing Action -> Store -> Api.get -> Api.got -> Action -> Store -> Action -> Api.get -> Api.got -> Store -> Store.trigger. Do you see any problem using this pattern in reflux?

[devinivy]

There is no limitation of which I'm aware. That said, it may be desirable to keep actions out of stores to mitigate hard-to-understand cascading effects.

[jamesmarrs]

I ran into a similar use case when I was experimenting with different pieces of code. A store could technically use this.trigger(INDEX_JSON) in fetching multiple models, or this.trigger(SHOW_JSON) to fetch one model with much more data, technically both child components could be listening to the store and could potentially get the wrong data it needs.

I found two Solutions to my problem:

You can do something like: this.trigger(JSON_DATA, "KEY"), and figure out which data I am supposed to use based on the key passed while in my view.

Use two separate actions that are only triggered in my stores show and index methods and have my components listening to these actions, instead of stores.

Thus changing the reflux lifecyle to more of a....

......... [Action] -> ........ [Store] -> ....... [Action] -> ........ [View Component] -> (start over)

So in your Component you have...
(this being the component)

Actions.modelUpdated.listen(this.updateUserCourse)

QUESTIONS:

1. Is there a better way of implementing this with the reflux lifecycle? I feel like I could be missing something.

2. I dont think I fully understand why you would specify a different bindContext on the listen method, possible to give a use case?

Thanks!

[devinivy]

The wiring between the store and the view is typically the hard part! If you want to use actions for that, I don't foresee any immediate technical problems, but it does bastardize the idea of a flux action a bit, so it might be confusing to those who are new to your codebase. Often one would trigger() to let the views know that some piece of a store has changed, then all views subscribed to that store would completely re-render. In the case of react, this is encouraged because the virtual DOM will still perform the minimal necessary changes.

If you need to broadcast more granular changes, I would suggest creating/finding some protocol that can describe those changes to the view and trigger() that. Otherwise, I suggest always to trigger() all of the state that your store contains so that your views know what to expect. If using actions floats your boat and works for your app, by all means go off the beaten path :) but I think you could potentially end-up with way too many actions to manage.

What view layer are you using? Is it react?

[jamesmarrs]

@devinivy Thanks for the response. Digging a little deeper I see why the more granular actions are not needed using react, even in more complex situations. Making a couple adjustments to how the stores are setup and utilized makes the reflux lifecycle become much more beneficial.