setState() called from outside an action handler about flummox

[acdlite]

Hmm. I've usually found it's best to keep async operations outside of store handlers and move them into either actions or controller-views instead. In the example you've given, for instance, maybe your controller-view (or whatever module is triggering the data loading) can check if the store has the data already before firing the action.

However, I realize that there will always be exceptions, and I certainly can't say it's always a bad idea to put async stuff inside your stores. Perhaps Flummox should have the option to disable warning messages entirely? With an environment variable, perhaps. Does that sound like a good solution?

[mark-bradshaw]

The warning is probably useful 99% of the time, but in this case I don't feel that I'm doing anything "bad" per se. I think it's definitely a good thing to be able to suppress the warning. An environment variable is fine. It would also be nice if there was a more "supported" means of doing async in store.

I did look over registerAsync to see if that would be helpful, but I couldn't drive the promise from the store side, so that didn't work out for me. One thing that might've been workable is if the promise had been passed to the begin handler, just like it is to the success and fail handlers. I guess that would be a breaking change, but it would open up a new pattern for me.

With that promise I think I could use the begin handler to initiate my async operations. Then when they complete I could resolve the promise with the correct data. Then my start handler would be called and I could set state there, and I'd be fine.

[acdlite]

I'm conflicted. I don't want to get in the way of people who know what they're doing, but I also don't want to encourage bad habits, and in my view, doing async inside of stores is almost always a bad idea. Even in your example, I'm unconvinced that it wouldn't be better to handle caching before firing any actions at all.

Regarding this part of your comment:

One thing that might've been workable is if the promise had been passed to the start handler, just like it is to the success and fail handlers

Success and fail handlers don't receive a promise; they receive the resolved or rejected value that is the result of a promise. We could pass the promise to the begin handler, but I'm not sure how that would help in your situation. If the request is already in progress, how does having access to the promise help the store do caching logic?

Back to the original issue, maybe one way to offer "support" for async in stores is with something like setStateAsync(), which accepts a promise that resolves to a state object. Again, though, I'm hesitant to officially support something like that out of concern it will be abused. Not opposed, but hesitant.

[acdlite]

Or I guess we wouldn't need a separate method. We could overload setState() to detect if a promise is passed, much how actions work.

Same concerns apply, though.

[mark-bradshaw]

I could get behind a setState that understands promises.

Maybe you could expand a bit further on why async in stores is a bad idea. I'm open to being convinced.

Otherwise I'd see this as a natural extension to asynchronous actions, just moving the work over into the store.

I'll spend a little time considering how my app my work if I asked my components to check cache first.

[mark-bradshaw]

I started reading on the net about async data loads, and it seems you are definitely in the majority in your views. So, I'll refactor my code to make sure that async happens outside the store.

http://fluxxor.com/guides/async-data.html
"The short answer is: in order to ensure that all the stores in your application have a chance to respond to the successful (or unsuccessful) loading of asynchronous data, you should fire additional actions from your asynchronous handlers to indicate when loading fails or succeeds."

http://www.code-experience.com/async-requests-with-react-js-and-flux-revisited/
"Asynchronously executed callbacks should not leak into Stores. The consequences of it are just to hard to fully foresee. This leads to elusive bugs. Stores should only execute synchronous code. Otherwise they are too hard to understand."

https://news.ycombinator.com/item?id=7721292
Gent from facebook (wingspan) gives a bit of a contradictory answer, but seems to indicate that data should be async pulled in actions.

etc. etc.