#2979 Add strict type inference overload for combineReducers.

[Shakeskeyboarde]

• Strictly infers state shape and actions from the reducers object map.
• Updated tests and comments to match new strict type inference.
• Tested and working in typescript 2.8.

[netlify]

Deploy preview for redux-docs ready!

Built with commit e26cb19

https://deploy-preview-3484--redux-docs.netlify.com

[Shakeskeyboarde]

This is a fix for issue #2979.

[timdorr]

This is basically what #3411 was doing, but without the BC breakage. I think this is good, but if others want to chime in, feel free.

[Shakeskeyboarde]

Apologies 😊. Habit from personal projects. Thanks for the heads up and fix.

[timdorr]

BTW, we're testing against 3.5.3 now, so compatibility with older versions isn't really of concern. I've found most people upgrade TS pretty regularly.

[pfgray]

Should we be encouraging shapes of reducers that include any type other than Action<any> as the second parameter? I'm afraid that reducers with specific action types aren't reflective of reality, since redux sends all actions to all reducers (even "private" redux actions).

For example, suppose we have this seemingly innocuous reducer:

type CounterAction = IncrementAction | DecrementAction
type IncrementAction = {type: "increment", amount: number}
type DecrementAction = {type: "decrement", amount: number}

function counterReducer(state: number = 0, action: CounterAction): number {
  if(action.type === "increment") {
    return state + action.amount;
  } else {
    return state - action.amount;
  }
}

The counterReducer believes it will only ever receive CounterActions, but we know this isn't true, since all redux reducers receive all actions!

This particular reducer produces a state of NaN, since TS indicates it's safe to assume any action that's not IncrementAction is a DecrementAction.

[Shakeskeyboarde]

@pfgray The intention here was to make the combined reducer consistent with the typing of the individual reducers.

You're right that maybe individual reducers should use AnyAction instead of specific action types. If you did that, then this would faithfully keep that AnyAction type on the combined reducer.

But, if you do use more specific types for your reducer action parameters, then currently that typing is stripped by combining.

Personally, I do specify types for my actions. But, I do it knowing I can't use an implicit else/default in my reducer. I add the types for testing (so I know when I'm testing an expected action), and for action property types when writing the code that consumes the action.

[pfgray]

But, I do it knowing I can't use an implicit else/default in my reducer.

I think we should make that implicit assumption explicit in the type system! That way less astute developers (like myself!) don't get tripped up.

I think the right approach would be to remove the first signature of combineReducers, which would prevent specific action-typed reducers, and would make this change unnecessary.

[timdorr]

So, aside from the AnyAction discussion, which is valid but better suited for another issue/PR, I think we're good here. Let's merge this in.