Root state properties being typed as never with redux 4.0.5.

[ryan-rushton]

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

bug

Prior Issues

Not that I am aware of

Bug Reports

What is the current behavior?

I am seeing root state properties being typed as never instead of getting a compilation error for mismatching types.

Steps to Reproduce

Basically when using typescript and combineReducer, if you are not using the slice function and instead creating pure function reducers, the types or the returned rootState are set to never. Being new to this library I got tripped up on this.

Downgrading to redux 4.0.4 gives different results depending on environment:

• Here in this Code Sandbox we see the type error produced with 4.0.4 and never with 4.0.5.
• In my local project running in VS Code I get the correct types coming through with 4.0.4 and never with 4.0.5.

I realise I didn't set up properly and the redux-toolkit docs strongly suggest to use createSlice with typescript, but I think this could point to an issue with the types. Also I was stumped for quite a while trying to figure out what the issue was, so if someone else has this hopefully this issue can point them in the right direction.

Finally using createSlice from redux toolkit fixes this issue.

What is the expected behavior?

To get either type errors or the return type of my reducers as root state properties

Environment Details

OSX Latest, VS Code and VS Code Insiders, Typescript as per the demo above.

[timdorr]

You're typing your reducer wrong. Use the provided Reducer type and it goes away:

const myReducer: Reducer<ReducerState> = (state, action) => {

[ryan-rushton]

@timdorr, it was more about the fact that I wasn't getting type errors from the compiler rather than making the example work.

Also the typescript docs mention nothing about typing the reducer state that way and instead just say to do it as per my example. I had a look around and can't see the documentation, otherwise I would make a contribution.

[markerikson]

The docs content is located in this repo, under https://github.com/reduxjs/redux/tree/master/docs .

You can preview changes by cloning the repo and running:

cd website
npm i
npm run start

to start the Docusaurus dev server.

[ryan-rushton]

@markerikson thanks! I will have a look at that after work and add the reducer typing. It would be nice if it did throw a type error though.

[timdorr]

Yeah, that ain't right. Sorry about the misleading docs.

If you don't get to it first, I'll try to take a look soon.

[ryan-rushton]

@timdorr, no worries at all. Just trying to help out where I can.

[ryan-rushton]

@timdorr I had a bit of a play around with that example and the issue with the typing being off seems to be with the type of the initial state. If you specifically type it inside the state parameter the correct state is inferred. Example below.

const initialState: ReducerState = null
const myReducer = (state: ReducerState = initialState, ...

Also this works

const initialState: ReducerState = ''
const myReducer = (state = initialState, ...

This leads me to believe the issue is with union types for state, particularly initial state.

With regards to contributing to the docs, I will thinking of adding a note in the typescript recipes section, after the example of combinedReducer. Something like

Using union types can cause an issue with the initial state's type inference, you may need to explicitly type your state parameter.

and leave it as that. Other way might be to explain why people might see never coming out as the type to their state, there is code (found here) to specifically type this as never if it cannot be reconciled. Does any of this seem reasonable?

[timdorr]

So, if you disable strictNullChecks (regardless of strict mode), it will be at least a string type. That makes sense because that mode basically treats a nullable type as optional, and our infer will put that back to the concrete value of string.

I'm guessing this is just a limitation of how far inferred types can go. It also goes to never if you use string | number as your state type, so something is breaking down when trying to track something that can be multiple unique/scalar types.

I think I would just push folks towards using Reducer. This all goes away if you use that, and it's slightly fewer characters as well.

[ryan-rushton]

Cool, that being the case I will have a look at the typescript section and see if it makes sense to modify it with that being included. I will see if I can raise a PR in the next couple of days.

[SrMouraSilva]

You're typing your reducer wrong. Use the provided Reducer type and it goes away:

const myReducer: Reducer<ReducerState> = (state, action) => {

Hello, @timdorr, it works! But it isn't present on the Usage with TypeScript documentation. The reducer topic doesn't informs the Reducer type.

Ok, I understood. If the initial state isn't defined with the type, the Typescript can't infer it. Maybe put on a side note will be interesting.

[markerikson]

@SrMouraSilva agreed, and I've just filed a new issue for us to rework that "Usage with TS" page in general.