Accessing other parts of the state, when using combined reducers

Question

NB: This is a question, very similar to Redux; accessing other parts... but it has nothing to do with Router :( thus cannot be solved s

Answer 1

Intro

I'd like to add an answer, which is based on my 3y+ experience and also recaps some of the other answers and comments above (Thanks to all the contributors)

Short Answer

An original combineReducers can be used. Every selector works with Root State. Reducer mutates only it's part of the Root State. Reducer is as thin as possible, and only Action (or Thunk) is responsible for collecting all the data, needed to reduce the part of the Root State

Detailed Answer

Application's reducers, actions and selectors are organised using Ducks approach. Using Redux Thunk gives lot of benefits (thanks to Leonardo).

If we use definitions of my initial question, one single "Duck" - is "one part of the state", and it groups following major items:

• Reducer (usually a function named %duckName%, receives )
• Actions and Thunks
• Selectors (which receive root state)
• Types (type, interface, enums)

State of the application - is an object. It's keys - are the names of all the "Ducks" that participate in reducing application's state.

Reducers shall be kept as thin as possible, as Leonardo has advised.

All of the Actions and Thunks, can be split into following categories:

1. Duck Action
   • no selectors inside
   • arguments have all the info, which is sufficient for independent work
   • returns Action object { type: "%actionName%", payload: ... }
2. Duck Thunk
   • no external selectors, but can have internal ones (selecting from the same Duck)
   • does dispatch of one or more Duck Actions.
   • might dispatch other Duck Thunks, but shall be avoided, as it leads to high complexity of the application.
3. Smart Duck Thunk
   • is aware of other Ducks existence, thus might select from other Ducks
   • shall not dispatch to other Ducks, as in this case, it might considered as Application Action
4. Application Action
   • returns Duck Action or other Application Action with modified arguments
5. Application Thunk
   • have selectors from any of the ducks
   • might dispatch any of the Thunk or Action

In some cases, you can have more than one Application in your codebase. Your Applications might share some of the Ducks. Sometimes you need to create Duck for every Application, so you can pass some configuration. But these are puzzles of a different story :)

I've tried to cover minimal portion of them in this repository, which I intend to keep contributing to. It's written using Typescript. I hope it makes it more easier to understand