the dispatcher wait doesn't actually wait for other callback? about flux

[bowd]

I'm not a maintainer, but as far as my understanding of flux goes, server side communication should happen in actions. The result of a server side communication should update the stores, to reflect the server response. Stores should (at least for the most part) be able to update synchronously.

[sterpe]

@bogdan-dumitru, this is my understanding too, and I can buy the logic of that, but I also wonder whether the inability to get any browser repaints while stores are digesting becomes problematic as a flux architecture application grows?

@maintainers, any thoughts on this?

[fisherwebdev]

Yes, @bogdan-dumitru is correct that the synchronous nature is intentional, and is required if we are to be able to cause the stores to update themselves only after the stores they depend on have been updated.

When communicating with a server, one should split the data flow at the point of creating an action. An example of this can be seen here: https://github.com/facebook/flux/blob/master/examples/flux-chat/js/actions/ChatMessageActionCreators.js#L23-28 -- in this example, we optimistically update the store with the client-side data. Then in the the XHR success or failure callback, you would create another action.

[fisherwebdev]

@sterpe I could imagine this scenario if your store logic was computationally expensive, but it's uncommon that the store logic is the bottleneck in performance. I've seen pretty crazy things like dispatches on a requestAnimationFrame cycle, and Flux/React handled them just fine.

One place where I did see some lag was in an initial data load, when the load was quite large. I'm not sure how we eventually improved that, but I'll try to find out and get back to you.