what if a store called an action which is listened by the store about refluxjs

[spoike]

Not sure if we're throwing error for this. The calls will be deferred, but it may still cause issues. We currently have circular dependency checks and some tests for them, e.g. this one, but not for this specific case.

The strategy is to throw errors (fail fast) since circular data flows is an error in design of the application that is being built.

[undoZen]

It's difficult to detect such things. I think it should be a convention that stores should not trigger actions.

[dashed]

Stores calling an action violates the unidirectional data flow of flux. You may instead output a warning for users to directly use the stores underlying an action they're using.

[undoZen]

Yes. If you want store A to notify store B that something has been changed, you shouldn't let store A call an action which store B listened to, instead just let store B listen to store A.

[spoike]

@dashed Well... the use case I know of is a store that handles web api, i.e. perform ajax requests. Since stores are designed to be listened on change events, they still need to send off HTTP errors from the requests.

Simplest way is to invoke an action that initiates flows for error handling so that components and other stores don't need to listen to errors they don't care about... alternatively is that the store sends a promise, but that makes things a bit more convoluted for error handlers.

[undoZen]

eeh..

I deleted my comment by accident...

[spoike]

Closing this issue since there isn't much that can be done practically. If you manage to get an infinite loop, you need to redesign the application's data flows so that it doesn't.

Common sense, unless anyone knows of a good way of detecting such calls without a taxing overhead.