Plans for this lib?

[markerikson]

Hi. I'm a Redux maintainer, and greatly interested in any approaches relating to Redux modularity. The repo looks empty at the moment. Do you have any working code yet, or are you just getting started?

FWIW, I have links to several other libraries that provide some form of modularity and encapsulation. I'm curious how your plans compare to any of those.

[klintmane]

Hey Mark, thank you for reaching out. I remember we had a little chat regarding this on reactiflux around New Year's Eve. At the moment I have some working code, which I haven't had the time to publish yet, will probably do so in the following days if everything goes smooth.

Anyway, the main goal of this project is to provide a way of easily composing modules by wrapping common module components (reducers, actions, selectors, sagas etc) into simple higher-order functions with little to no configuration. Ideally it will also expose an API for modularizing custom components not included in the library.

Comparing to the links you shared, my approach feels less alienating to new React/Redux users and pretty much straightforward. That may however be relative until I get a second opinion (hopefully yours).

[markerikson]

Sure. Ping me when you've got something you think is ready to share, either here, on Twitter, or in Reactiflux.

[klintmane]

Sure, will gladly do so as soon as I have something.

[klintmane]

@markerikson Hey Mark, PM-ed you on Twitter as well, letting you know I released v0.0.1 of this project.

[markerikson]

Hiya. Glancing at it a bit... I guess I'm not seeing enough of the big picture use case. Most of the snippets in the docs seem to be about wrapping up standard Redux logic with some bits of dependency injection. Skimming through the example project, I at least see a spot where you're instantiating multiple copies of a "module", which tells me a bit more.

I think the docs would really benefit from a higher-level overview of what this does, what problem it solves, the benefits you get, and how to use it, in addition to the current "before/after" snippets.

[klintmane]

Yep, the docs are missing a lot due to a lack of free time on my part.

The big picture with this is that each Module can be self-contained and a totally different project. You don't care where each Module is located, it can be local, or it can come from a different repository. It is self contained in the sense that it's totally functional on it's own, and the same functionality can be achieved by just importing the module, no implementation needed by the importing module.

Module instances can communicate with each other through dependency injection and modules can render views of their dependency wherever they see fit, mount their reducers wherever they want, dispatch their actions easily (ex. Module.actions.myDep.doSmth, and everything is scoped to each module instance, so you can have an infinite number of those, without them ever affecting each other).

These features are completely up to the users, they are not limited to actions and reducers, I've personally used the instances for epics, sagas, theming, localization and more. You just add a custom feature name when creating the module and the module instance is passed to the feature export. The best part is the whole process of doing this is 100% customizable.

In a case of mine, big projects (ex. a third part integration modal) are declared as seperate lerna packages and exported as modules which are then composed into a bigger project. Different teams are working on different modules and the core project just imports them and wires them up.

[klintmane]

A great example of this would be notifications.

You can create a notification system module and create some instances of it.

Different parts of your app can choose where to render the notification view, some might not render it at all, you can render a global instance (ex. at the top), some parts can also have local instances (ex. one to the right for errors, one to the left for info) and this would be as easy as just dispatching an action of the instance Module.actions.notificationInstance.add.