Nested reducer injection

[wafflepie]

Copy pasted from an internal project:

{ 
  someModule: {
    common: {}, // App bound
    someView: {}, // View bound
  }
}

but when you navigate from SomeView to OtherView, you would get

{ 
  someModule: {
    common: {}, // App bound - preserved across navigation
    otherView: {}, // View bound - fresh initialized
    // someView gets dropped
  }
}

Of course the same can be achieved by using prefixed names like someModuleCommon or someModuleSomeView, but the nested variant looks nicer.😃

[wafflepie]

To whoever will implement this, here is my analysis.

Currently, we are able to build a root reducer using combineReducerEntries. The approach is to first build a schema:

{
 a: {
  b: {
   c: reducer
  }
 }
}

and then calling the recursive deepCombineReducers on this, resulting in:

combineReducers({
 a: combineReducers({
  b: combineReducers({
   c: reducer
  })
 })
})

To fix this issue, we must be able to consume nested objects: createEntries should retrieve a path to the inner functions.

{
 a: {
  b: {
   c: reducer
  }
 }
}

The injectables above should result in a key: ['a', 'b', 'c'] entry.

Furthermore, the constructed schema structure should be changed into something like this:

{
 a: {
  b: {
   c: {
    _ROOT_: [reducer]
   }
  }
 }
}

This will allow any given combination of keys to be processed (even a mix of a, a.b, a.b.c. We will be able to have multiple reducers on the same path, allowing e.g. injection of "hyperglobal" reducers (#75).

tl;dr store array of keys in entries, make deepCombineReducers consume the schema above.

[wafflepie]

https://github.com/ramda/ramda/wiki/Cookbook#flatten-a-nested-object-into-dot-separated-key--value-pairs might help

[wafflepie]

we should tackle #100 at the same time: if createEntries receives an array, it shouldn't store anything as the key. also, maybe key should be renamed to sth like path??