redux.md

gistfile1.txt

1. Action Names: 

these are constants (usu. strings) that are the names that identify what you are doing. Think of it like the names of functions. An action is a name-payload pair that moves through the Redux/Saga state system. This is a formalization of a function call

2. Action Functions: 

These take in arguments and return an object in the form

 {
    action: <<string>>
    payload: <<any>>
  }
  
that becomes a message object that moves through Redux. 
* note - the format an action is a convention -- albeit a heavly preferred convention; there
are no hard rules in Redux about what an action looks like. 

3. State

State is the "thing that redux changes". There are no rules about what state has to be - it could be a string, a number, an array or whatever.

Usually state is an object with properties (like React component states).

In McK, state is an immutable Record. This is an object-like instance with named properties that can be referenced like object properties --- EXCEPT:

* A record has methods that return an immutable copy of itself, with changed property(s).
* A record has default property values; if you initialize a Record with missing properties, it will provide those properties as defaults
* A record cannot have properties added to it or removed from it; the property list of its default object must contain all the properties it will ever need. 
* Records mutate by calling the record method myRecord.set('location', 'Paris')` or myRecord.setIn(['location'], List('Paris'));

Record property values can be anything -- immutable or not-immutable. However, in McK, usually complex data items like arrays or objects are comverted to immutable List or Map instances. 

```JAVASCRIPT

const defaultState = {
  [keys.locations]: List(),
  [keys.locationsRequestStatus]: RequestStatus.UNINITIATED,
  [keys.locationsError]: {},
....
};

class UserGroupsEditorStore extends Record(defaultState, 'UserGroupsEditorStore') {
  setLocationsRequest(locations) {
    return this.setIn([
      keys.locations
    ], List(locations));
  }
  
  ...
  }

4. Action Reducers: 

Every store has a global function that every action goes through. it is usually a global case/switch that takes in a state and action and returns a mutation of the state. 

In McK, 

``` javascript

export default (state = UserGroupsEditorStore, action) => {
  switch (action.type) {
    case UserGroupsEditorActionTypes.USER_GROUPS_RESOURCE_GROUPS_REQUEST:
      return UserGroupsEditorReducerWorkers.reduceResourceGroupsRequest(
        state,
        action.payload.searchText
      );

.....

    case UserGroupsEditorActionTypes.USER_GROUPS_LOCATIONS_REQUEST_SUCCESS:
      return UserGroupsEditorReducerWorkers.reduceLocationsRequestSuccess(
        state,
        action.payload.locations
      );
	}
};

---- in reducerworkers:

const reduceLocationsRequestSuccess = (state, locations) => state
  .setLocationsRequest(locations)
  .setLocationsRequestStatus(RequestStatus.SUCCESS);

```

so, the reducer is a switch that calls a worker with an action and the current state, 
and that worker calls a method of state to inject a value of the action into the state.

A super simple example of this might be: 

``` javascript
STATE:

const state = new Record({count: 0}){
	addToCount(n) {
		return this.set('count', this.count + n);
	}
}

ACTION: 

const increment = (n) => ({action: 'INCREMENT', payload: n})

REDUCER: 
function(state, a) {
	switch (a.action) {
		case 'INCREMENT': 
			return state.increment(a.payload)
   		 break;
	}
}
```

Part II: Sagas

Sagas are listeners that sit on top of a reducer and spy on actions. they have watchers
that are in the form of generator loops, that take in actions and call functions (the saga)
that respond to the action. 

Unlike Redux which is synchronous -- the change to state happens immediately when you call 
an action, though it might take some time for that notification to percolate through to
a redux component -- Sagas use generators to allow for asyncronous flow.