client.md

##Thoughts on flux, actions, and doing work in a Flux app

Reference for what I am considering to be "conventional" https://github.com/facebook/flux/tree/master/examples/flux-chat/js

###Many Files This the conventional scheme uses an action flow that goes from Component -> ActionCreator -> APIClient -> ServerActionCreator Problems

• Implementing request/response API call requires edits on 5 files Constants, ActionCreator, APIClient, ServerActionCreator, Store
• ServerActionCreator methods are almost always passthrough boilerplate

###Naming Conventions Part of the confusion stems from the naming conventions. Problems

• Actions are actually just action objects handed to the dispatcher. They do no work other than transporting information (the stores then do some state mutation work)
• ActionCreator is difficult to type and lexically confusing.
• ActionCreator sounds like it creates the actions (it does) which are just objects, so we might expect no other work to be done here. But by convention ActionCreators actually trigger real work (read: API calls via a client), perhaps a more descriptive name would be "Routines".
• In practice ActionCreator typically emits 1 action before handing off work a worker. Often times the ActionCreator method and the Action type are different
  • EG: ActionCreator.login -> Client.login() && Dispatch(LOGIN_REQUEST_PENDING)
  • Making the translation .login to LOGIN_REQUEST_PENDING is unecessary mental load

###Client Centric Scheme Proposed Solution

• Instead of having ServerActionCreators, move all server/api call methods into "Clients".
  • Clients dispatch actions directly (no ActionCreator step)
• Keep ActionCreators for app specific actions like SET_MYFORM_DATA

Ostensible Benefits

• More lexically descriptive (although the Action/ActionCreator dichotomy is still a bit confusing)
• Implementing request/response API call requires edits on 3 files Constants, APIClient, Store
• The entire flow of the action routine is contained in 1 method making it easier to reason with and isolate debugging

Possible Drawbacks

• This reduces one level of abstraction, so changing the behaivor of (conventional scheme) ServerActionCreator.login() will now require editing all methods where Dispatch(LOGIN_SUCCESS) exist.

ActionType Naming Conventions (side note)

[RESOURCE]_[METHOD]_PENDING
if requires direct response
[RESOURCE]_[METHOD]_SUCCESS
[RESOURCE]_[METHOD]_ERROR
if requires model update
RECEIVE_[RESOURCE]