Experiencing TypeScript mismatches between preloadedState and configureStore

[binarykitchen]

Good evening again,

Great discussions before. I'm getting closer, although experiencing some TypeScript mismatches. The configureStore fn is not accepting the typings of my preloadedState:

Error:

Type 'undefined' is not assignable to type 'Partial<{ options: VideomailRecorderOptions | undefined; }>'.

To reproduce:

1. git clone git@github.com:binarykitchen/videomail-recorder.git
2. npm install
3. npm run types

The configureStore fn believes the preloadedState can be undefined, which is wrong:
https://github.com/binarykitchen/videomail-recorder/blob/main/src/root/store.ts#L7

In my case, the preloaded state should be always defined, never undefined. Running the library with undefined options is a no-go. So, I believe, the problem is how to extract the correct type for the preloadedState from root reducers.

What I do for now:

export type PreloadedState = Parameters<typeof rootReducers>[0];

See: https://github.com/binarykitchen/videomail-recorder/blob/main/src/root/types.ts#L6

Because it's accessing an array I reckon, that's why configureStore believes it can be undefined.

type PreloadedState = {
    options: VideomailRecorderOptions;
} | Partial<{
    options: VideomailRecorderOptions | undefined;
}> | undefined // <--- Here, it's undefined but that's wrong. In my code there is always a preoloaded state, never undefined.

I understand that the state is always at index zero, although this conflicts with TypeScript.
Is there a better recipe to define the type of the root state based on root reducers rather than using an array index?

Thanks.

[EskiMojo14]

#5208 (reply in thread)

you're using exactOptionalPropertyTypes, so you'll need to replace preloadedState with ...(preloadedState && { preloadedState }).

[EskiMojo14]

Thanks. In English, what is this code doing?

It's only spreading in the preloadedState option if it's defined. exactOptionalPropertyTypes prevents you from passing undefined to keys marked as optional.

And secondly, accessing states from an array of index zero doesn't seem stable. Is there a better way to access the root state from root reducers?

#5208 (reply in thread)

every single redux reducer is (state, action) => nextState. it's been that way for over a decade. if you tried to pass (action, state) => nextState many things would break.

as a redux maintainer, i can promise you we have no plans to change the order of arguments to reducers. it would be an insanely breaking change for the ecosystem, and virtually every redux library would have to be updated.

[markerikson]

accessing states from an array of index zero doesn't seem stable

I think you're asking two things here:

• why is the "array" necessary?
• is this risky or could it break somehow?

What that TS type is doing is:

• get the "function type" of the root reducer function
• Parameters retrieves an array/tuple of "all of the individual argument types for this function type". Every reducer is (state, action) => newState, so the argument type tuple is [RootState, SomeActionType]
• Therefore, we can extract the type of RootState by accessing index 0 of the tuple

although I think our usual idiom is just ReturnType<typeof rootReducer>, so that ought to work as well - every reducer receives the state as its first argument, and returns the same type sorry, we're dealing with configureStore here. Yeah, Ben's right that we're trying to get the PreloadedState type here.

[binarykitchen]

Ah, thanks, finally. Now no more TS errors. I'm learning 🧠

Here's the latest code:
https://github.com/binarykitchen/videomail-recorder/blob/main/src/root/store.ts#L13

A couple of further comments/thoughts:

It's only spreading in the preloadedState option if it's defined. exactOptionalPropertyTypes prevents you from passing undefined to keys marked as optional.

@EskiMojo14 I'm not a fan of spreading syntax as it makes debugging harder. Is there another way to do so without spreading syntax? Do you provide any helper functions to handle this better, or know any libraries for this?

as a redux maintainer, i can promise you we have no plans to change the order of arguments to reducers. it would be an insanely breaking change for the ecosystem, and virtually every redux library would have to be updated.

@EskiMojo14 I see. That's why index zero. Still, it feels too "magical" and odd.

Something like this would be a lot more user friendlier:

export type PreloadedState = Parameters<typeof rootReducers>["state"];

But since you promised you won't change, I'll accept it for now. Still, I wonder whether that's something that might put off some newbies trying RTK and go back to Zustand?

Thank you again for your great, quick replies.

[markerikson]

@binarykitchen I'm not sure where that suggestion is coming from tbh :)

This is a TypeScript representation of a function and its arguments:

function doSomething(a: string, b: number, c: MyType) { return 42 }

// (a: string, b: number, c: MyType) => number
type DSType = typeof doSomething

// number (because it returns 42)
type DSReturn = ReturnType<DSType>

// [string, number, MyType], because those are the types of a, b, and c
type DSParams = Parameters<DSReturn>

so DSParams is a tuple. It's indexed numerically. You can't use a field name on it. someArray["state"] is... okay well it's legal JS, but that's not how you use an array. You use someArray[7].

So, if a reducer's arguments are (state: SomeState, action: SomeAction), then Parameters<typeof someReducer> is [SomeState, SomeAction]. And to get "the type of the first thing in that tuple", you use index 0.

No magic. Just normal array indexing.

So A) that's how TS works, and B) that's how Redux works, and neither of those will ever or can ever change :)

I'm not a fan of spreading syntax as it makes debugging harder. Is there another way to do so without spreading syntax? Do you provide any helper functions to handle this better, or know any libraries for this?

I'm also pretty confused here. There's nothing to "debug". This is TS type syntax. And no, there's no libraries for this. This is TS types behavior, which you need to get this scenario to work with your preferred TS compiler options.

[binarykitchen]

True. Thanks for the examples.

someArray["state"] is... okay well it's legal JS, but that's not how you use an array. You use someArray[7].

Yes, I went into that JS trap. Now, with your examples and the emphasis on tuples, it makes "click" in my head.

All clear now.