TypeScript definitions allow a reducer that doesn't handle all possible actions

[Mossop]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

If the current behaviour is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar.

I'm using TypeScript and hit a situation where I managed to register my main reducer as only receiving my specific types of actions. This is a simplified version though somehow in my real case I managed to make the reducer not even need to accept undefined for the state: https://gist.github.com/Mossop/2871372747e55e0fedea64eb649067e6.

This compiles correctly with TypeScript because TypeScript thinks I have handled all possible actions, and returned a valid state however this is incorrect. My reducer will actually receive other actions such as the INIT action that redux sends when the store is first created. When this reaches my reducer it just returns undefined and now my store is in an unexpected state.

What is the expected behavior?

Obviously I can fix this by just always putting return state at the end of any reducers, but I think that TypeScript should catch this case, createStore should only accept a reducer of the form (state: S | undefined, action: Action) => S

Which versions of Redux, and which browser and OS are affected by this issue? Did this work in previous versions of Redux?

I'm testing with 4.0.4, haven't tried any other versions.

[nickserv]

Redux has recently been ported to TypeScript which may fix this issue, though it hasn't been released yet. Maybe you could try building it from source.

[timdorr]

This is because we coerce the INIT and REPLACE actions to your Action type:

redux/src/createStore.ts

Line 340 in 25f8a6c

dispatch({ type: ActionTypes.INIT } as A)

redux/src/createStore.ts

Line 286 in 25f8a6c

dispatch({ type: ActionTypes.REPLACE } as A)

Perhaps we can make something like reducer(state: State, action: ReduxActions<MyActions>) => State that will include the internal actions?

[Mazuh]

@timdorr could you follow up the discussion that @markerikson started with me at #3582 ?

I recently started to study TS and I always use Redux, so I got interested in this issue

[timdorr]

So, we basically lie and say these special actions with randomly-generated types are actually set with the types you define. Your own Action type (which extends our Action type) is going to specify the the type field to a known set of values (essentially, an enum). So our casting of the internal action types will create a scenario where TS will pass the types, but produce incorrect code.

More specifically, in @Mossop's example, that would produce an error if used with combineReducers when it attempts to probe an unknown action. And it would produce a state of undefined when creating the store (from the INIT action), which may be fine, but is probably unexpected and will likely cause Cannot read property 'foo' of undefined errors.

So, the core problem is we're preventing TS from doing its job effectively and creating the potential for bugs to go unnoticed.

[Mazuh]

@timdorr and that solution I implemented isn't really an option (available on current design)?

[Mazuh]

I'm not sure of how it's possíble for the user to implement a typed-safe reducer without somehow being exposed to all possible actions.

[timdorr]

I don't think you were totally wrong, but I think I was wrong about having a separate ReduxAction. We should keep our types as similar as possible.

Here's a better example of what I'm thinking of.

Note that the return type of the reducer fails in that case. The previous example will still fail to catch the bug, but it's fully BC with existing code that way. At least you now have the option to add some more safety.

[cellog]

Step 1: can we make a PR with a failing typescript test that can be iterated on to solve this?

[r3dm1ke]

Hi! I am trying to write a failing typescript test that we can use for this, but I ran into errors with running jest: it will complain about not being able to parse ts code, for example:

import { createStore, combineReducers } from '..';
           ^

    SyntaxError: Unexpected token {

when running npm run test. Is that a well-know issue that has a solution, or is it a local problem on my end? I am running this on Windows, if it matters.

[jsnajdr]

We ran into a similar (or exactly the same?) issue where the reducer type incorrectly constrains the set of allowed actions.

The Usage with TypeScript guide recommends typing the action parameter as the union of action types the reducer specifically reacts to:

function chatReducer(state = initialState, action: ChatActionTypes): ChatState {
  switch (action.type) {
    case SEND_MESSAGE:
      return ...;
    case DELETE_MESSAGE:
      return ...;
    default:
      return state;
  }
}

But that's too constraining. A Redux reducer must expect and correctly handle any action of the general-purpose Action type, i.e., an object with a type field.

TypeScript then refuses to compile 100% valid code that calls the reducer:

chatReducer(undefined, { type: 'FOO' });
createStore(chatReducer).dispatch({ type: 'FOO' });

Both these statements fail with:

Type '"FOO"' is not assignable to type '"SEND_MESSAGE" | "DELETE_MESSAGE"'

If I understand the current types correctly, they are great for providing autocomplete hints, but are not that good at the main job of type checking, i.e., checking correctness of the compiled program.