[fluxible] Consider adding executeAction to store context

[mridgway]

Bill Fisher's talk and some of the Flux articles talk about performing API calls directly from the stores. The responses from these API calls should always go through an action creator, which would require access to the executeAction method.

The fluxible-plugin-fetchr should also be updated to expose the service methods as well.

[acrispino]

I would like to see this as well, for the same reasons cited in the Ian Obermiller interview.

For now, I've been working around it by putting more "smarts" into my components but I'd rather not.

[trshafer]

My understanding is that stores should not be interacting with an API. Only Action Creators should interact with the API layer according to this diagram: https://github.com/facebook/flux and this article: http://facebook.github.io/react/blog/2014/10/17/community-roundup-23.html#async-requests-with-flux-revisited .

[acrispino]

I think you're right about that but in this case, what's at issue is whether or not stores should have access to action creators or not.

[mridgway]

Exactly. The idea is that stores could call an API themselves and then call an action creator when the response has come back. This is how some other Flux implementors are doing it.

This isn't as easy as just exposing the executeAction method to the stores though. We have to make sure that we can track when a store has completed its async calls so that we know when it's safe to render the markup on the server.

I have some ideas of how we could do that, but it would require some changes to the way that actionContext and storeContext work.

[bsr203]

+1. I've been thinking aloud about this in the gitter room, and @koulmomo pointed me to this. I feel it right to have the domain/store which knows the state of data to trigger the action, raise a PENDING event, and the result comes through the dispatcher. Please let me know you also felt the need of it and would be considering to implement this. thanks

A SO post where Bill Fischer and Brandon (Fluxxor) agrees with this approach.
http://stackoverflow.com/questions/26632415/where-should-ajax-request-be-made-in-flux-app

[longlho]

👍 for this too. The article @mridgway mentioned having only write actions instead of read, which to me kinda makes sense. Right now we don't think we have a layer that controls data freshness (whether to pull from memory, cache, localStorage... or fetch) and since Stores have the data that makes it an ideal layer to have that control. Which means Stores might need a way to fetch data directly.

[quangv]

👍 I was thinking about this for a bit, I like the purity of the one-way data flow. At the same time right now I'm trying to leverage flux-router-component's CHANGE_ROUTE_SUCCESS to fetch some data.

Also the whole localStorage vs fetch use cases is intriguing.

Update:
I forgot that you can assign actions to routes, so that solved my problem.

[marnusw]

+1

I was about to create an issue on this myself just now. I'd be happy to help out developing this if it would speed things along.

[phuson]

+1

[marnusw]

For use until this is supported natively in Fluxible I've created marnusw/fluxible-plugin-store-execute-action.

[aocenas]

Not sure if anybody is still thinking about this, but we went form vanilla flux -> reflux -> fluxible and from being able to dispatch action from store to stores without access to dispatch. Because you have access to stores from actionCreator context, you can always check what data you already have and decide accordingly how the action actually get the data. This makes actionCreator more complex, but reduces complexity of the store which was more beneficial for us when our application got bigger.