Inconsistent description of stores?

[adamdonahue]

In your section on dealing with asynchronous data, you listed actions that contain business logic, namely the implementation details for interacting with the client.

Yet earlier in the document you state that stores are where the business logic should be contained.

I'm just curious if there a specific reason you put this logic in your actions instead of the stores themselves.

[BinaryMuse]

Thanks for the note! Perhaps this isn't as clear as it could be in the documentation.

Stores contain the logic for manipulating the application state that is used to build the UI and otherwise provide useful data to the application; this is what I generally refer to as "business logic" in a flux system, but perhaps a more accurate term would be "global state management logic." No other part of a flux application should manipulate the global app state. Async client interactions happen in the action creators, but these (in my mind anyway) don't contain what I'd consider "business logic"—they're generally just thin calls to an API endpoint that invokes the proper server business logic to act on the data on the back end (database, etc.) and return the data to the client when the operation has succeeded or failed. All the logic about how that interaction changes global application state happens in the store in response to an action dispatch.

For example, in the BuzzwordClient example, the addBuzz action creator function doesn't contain any client-side state management, it just takes the parameters given to it and contacts the (fake) server endpoint that corresponds with "add buzzword" with it. When the server responds with the success or failure to actually add the word, the action creator notifies the store with the ADD_BUZZ_SUCCESS and ADD_BUZZ_FAIL, and it's the store's job to manage the internal state that the UI is ultimately based on.

Does that help or make sense? I'm totally open to ideas on how to make this more clear in the docs.

[adamdonahue]

Thanks for the feedback.

I see what you are saying, and it makes sense. I still think the line between what a store does and what an action does is blurry in Flux, in general, and I'm always interested in hearing another take on things. Another pattern I've seen used is one in which a model fetches its data and then updates a store via an action. (This always feels wrong to me.) Then there is the argument that the asynchronous call itself could go into the store action handlers.

In any case, I'll muse on this some more, but also looking forward to putting Fluxxor into practice in an application soon.

[BinaryMuse]

I think a lot of that doesn't matter so much as long as you're consistent. In my opinion, the two big "rules" (that help make flux apps easier to reason about and debug) are:

1. All global app state lives in the stores, and only a store is allowed to modify that store's state
2. All store state updates must be synchronous updates triggered by handling actions

These two rules mean that any issue with global app state can be traced back to a single action or action handler.

[adamdonahue]

Makes sense, thanks for the clarifications.