Test what it would look like to define redux logic with config files

[tribou]

The idea would be to find a harmonious balance to hide much of the redux boilerplate behind tests that expose a configuration API. This is similar to how Hapi.js hides implementation details by exposing an extensive configuration API. We would want to balance where to pass functions and where to pass strings/objects. i.e. redux-config might have too much magic?

This would help because:

• Implementation details/boilerplate could be thoroughly tested by the framework rather than each project/reducer
• A configuration object is easier to validate via types or Joi schema
• It should make it simpler and faster to create entire redux modules
• There may need to be an "escape hatch" or way to create a manual redux module when needed.

[tribou]

Another interesting spin on this concept:

https://github.com/infinitered/reduxsauce

Downside is it doesn't adhere to the Flux Standard Action shape. Also, the lib is used by boilerplate that relies heavily on redux-saga for moving all side effects out of action creators (rather than using redux-promise-middleware. To compensate, if we used this lib, it might make the most sense to use redux-observable more frequently. But with observables being inherently difficult to debug still, that doesn't sound like a good trade-off.

[tribou]

Redux docs offers example of creating a reducer based on configuring action handlers: https://redux.js.org/recipes/reducing-boilerplate