#168 Multiple instances/Request option caching in redux for middleware customisation

[mspae]

Fixes #168

This PR contains two things (which build on each other) but which for the purpose of explaining what's going on I will seperate:

1. There are two new actions API_WILL_REQUEST and API_DID_REQUEST which cache ALL the request data (endpoint, data, axiosConfig etc.) in the redux store before each request. This happens purely so that middleware can hook in and change stuff. The data is then immediately read out again and used for the request. After the request the request data is deleted again by using the second action. This means request options can be built from multiple sources (by order of superiority):

   1. If defined: Customisation Middleware
   2. option parameter (the second parameter of each API action)
   3. global axiosConfig (only for the axiosConfig part obviously)
   4. API-action-specific options (i.e. the updateResource uses the POST method)

2. There is now a stateKey property in the reducer. If this is defined and if there is a stateKey property in the action payload then the action is only applied if they match up. (Since this is part of the requestOptions (see 1.) customisation middleware can select between instances) This way it is possible to have multiple instances redux-json-api if needed. To make this easier to set up this PR adds a createInstance function which returns a reducer and actions which are bound to this instance.

This should be fully backward compatible for people who want to stick with a single instance and not bother about customisation middleware.

An example of the instance API in use:

const { reducer: instance1Reducer, readEndpoint: readEndpoint1 } = createInstance('instance-1');
const { reducer: instance2Reducer, readEndpoint: readEndpoint2 } = createInstance('instance-2');

const store = createReduxStore(
  combineReducers({
    'instance-1': instance1Reducer,
    'instance-2': instance2Reducer
  }),
  composeEnhancers(applyMiddleware(thunk))
);

// use readEndpoint1 and 2 as you would normally ...

Some notes for @egeriis

• I removed the default options parameter on the readEndpoint function. It was messing with the API action binding. This should not break anythin however, because there are very (strict checks in place)[https://github.com/redux-json-api/redux-json-api/blob/master/src/state-mutation.js#L100] when this is used.
• The part in each action handling in the reducer where it checks whether there is a stateKey and if it is the correct one could be refactored out into a utility function of course but I found this to be by far more readable.

… also sorry for the giant PR! 🤕

[egeriis]

Oh, this looks great @mspae! Please allow me a few days to review it thoroughly. Think we're looking at a new major version, since there are no backward compatibility.

[mspae]

Sure. No hurry. As far as I can tell this PR is actually fully backward compatible.

[egeriis]

unpacking options in the end, wouldn't that override axiosConfig as specified above, if present in options? i.e. rendering L237 useless. I don't see a test case for this, maybe that's relevant to add.

[mspae]

True. Will change that.

[egeriis]

Had a chance to look today. This looks great and I would be very happy to have this merged asap. I would request that you add some documentation of the changes you've made, with some usage examples.

I also think we need more tests to cover the various ways options can be passed now, thoughts?

[mspae]

Nice! Happy to hear that. I will add a more comprehensive documentation and test cases for the different ways to use options once I have some free time. 👍

[egeriis]

@mspae Appreciate it and love that you're willing to spend a bit of time and effort on this project