I'm a big fan of Redux, but I am leery of forcing all applications to use a single Redux store. It makes assuring for large application composed of sub-applications a nightmare.

Composition works best when the internals of every service are hidden behind a relatively small and fixed interfaces. In a fat web client, Redux world this implies that every service should have its own Redux store hidden behind the public interface. I can see three immediate benefits:

1) It eliminates the possibility of namespace pollution. When the reducer is exported every service sees every action request. If there is a naming conflict in the action.type property (e.g. action = {type : "ADD_IMAGE", ...}) then all packages using that type will attempt to modify their branch of the state tree whenever an action of that type is dispatched, even if the action was intended for another package.

2) Breaking the overall state tree up reduces complexity. Yes, I know that run time is not a major issue given the speed of JavaScript operations, but at least it's not a negative.

3) It opens up the possibility of rapid integration of non-Redux sub-applications in Redux applications, and vice versa. This isn't critical for small applications but is critical for people who maintain large and legacy systems. Sure, most fat clients today are little more than big web pages, but that will change as developers learn to build bigger systems.

The downside, of course, is that multiple stores breaks the wonderful "all state is in one place" feature of Redux, so I also like the idea of exporting reducers. I just want an option of isolating sub-stores in sub-applications for really big systems.

So for me the feature request that makes the most sense is being able to nest Provider elements. This would enable package creators to isolate their packages from the main application by installing a new Provider element in the root component of their package. If this nested Provider replaces the main application's store with the package's store for all the children then this would nicely isolate the package's state from the main application's state, and vice versa.

Does anyone know if this is already what Provider's do? Will they stay this way, or is this just an artifact of how they are constructed. Seems to me that it could be made an explicit requirement in the spec without breaking the 99% use-case single-store applications.

my 2 cents.

Hey Dan, we are working on something that should help to create Redux "modules".

Give it a look later https://github.com/choko-org/choko-redux ; it's in early stages yet, but we believe it already helps you to organize and re use a combination of reducers & middlewares.

The team that is working on the project (including me) are part of the Drupal CMS community for many years, so we are trying to get out of Drupal the best key features which makes it so extensible.

I hope you could give us your opinion about the approach we are taking.

I built a framework around React/Redux that supports composable modules with module based route configuration, automatic react-redux bindings and a lot of other magic. Once I have time to separate it from the application I'm working on I'm going to open source it on GitHub. In the meantime feel free to contact me and I'll share some examples. A module definition looks like this right now: https://gist.github.com/mbensch/830af5e065b2d69b1fb7

It's worth comparing to the elm architecture which composes very naturally.

have you seen ducks? https://github.com/erikras/ducks-modular-redux

it seems that the npm convention is "thing-lib-dep" see "react-router" and "react-router-redux"

so if you have a component that isn't redux aware, then wrap it and make it redux aware and expose that. in that case we're starting to coalesce around the default export being a reducer, and then exporting an actions object and an actionTypes object (if necessary).