aappddeevv

If you need a redux reducer that adds some "injectables" as the third argument to the reducers normally combined in redux's combineReducers, try this one:

/** 
 * A combineReducers replacement that adds additional arguments
 * to the reduction call to inject different values a reducer
 * might need, read-only, from other parts of the tree. Reducer
 * order calling is not specified. If no injectables are provided
 * the overall state is included under the key "_root_".
 *
 * @param {Object} reducers Reducer object. Each key with a function is included in a final reducer.

aappddeevv

#The Problem We just described standard design issues you have when you start creating layers of services, DAOs and other components to implement an application. That blog/gist is here.

The goal is to think through some designs in order to develop something useful for an application.

#Working through Layers If you compose services and DAOs the normal way, you typically get imperative style objects. For example, imagine the following:

  object DomainObjects {

aappddeevv

Scala and Cake Patterns and the Problem

Standard design patterns in scala recommend the cake pattern to help compose larger programs from smaller ones. Generally, for simple cake layers, this works okay. Boner's article suggests using it to compose repository and service layers and his focus is on DI-type composition. As you abstract more of your IO layers however, you realize that you the cake pattern as described does not abstract easily and usage becomes challenging. As the dependencies mount, you create mixin traits that express those dependence and perhaps they use self-types to ensure they are mixed in correctly.

Then at the end of the world, you have to mix in many different traits to get all the components. In addition, perhaps you have used existential types and now you must have a val/object somewhere (i.e. a well defined path) in order to import the types within the service so you can write your program. Existential