Namespacing Actions for Redux

Summary

Kickstarter’s front-end team encountered a Redux action-namespacing problem when multiple instances of the same functional React component responded to actions intended for only one instance. They rejected local state because the application used functional components and redux-loop, which routes state updates and side effects through reducers, and they sought programmatic namespacing compatible with combineReducers and a low-surface-area component API. The team compared nested reducers, higher-order reducers, and a closure-based module pattern; the latter met the stated constraints with namespaced actions, wrapper components, reducers, and a namespace returned by a factory that defaults to a UUID. Namespaces must be preserved when reducers trigger further actions, including redux-loop results, and complex composition can lose the required binding. The approach has worked for most reusable and compound components, while possible performance costs from many reducers remain a future concern.

Takeaways

1. 1

   The module-pattern solution met the requirements for avoiding local state, supporting combineReducers, enabling programmatic namespacing, and keeping instantiation to state and dispatch.

2. 2

   Actions dispatched by reducers must retain their namespace, including actions returned by redux-loop; the implementation usually binds actions to reducers during initialization.

3. 3

   The approach has worked for reusable and compound components, but lost bindings in some complex compositions and may face performance costs if the number of reducers becomes too large.