TypeScript: Excessive stack depth comparing generic preloadedState with DeepPartial

[hswhite33]

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

What is the current behavior?
Passing a generically typed preloadedState parameter into createStore creates an "Excessive stack depth" error in TypeScript due to the comparison between S and DeepPartial<S>

Sandbox: https://codesandbox.io/s/busy-leavitt-wrpnx?fontsize=14

More information at microsoft/TypeScript#21592 (comment) - this is caused by a TypeScript bug, but the TypeScript devs have suggested that Redux may not actually need to be using the DeepPartial type here.

What is the expected behavior?
No TypeScript errors

Which versions of Redux, and which browser and OS are affected by this issue? Did this work in previous versions of Redux?
In theory this affects any version of Redux using the DeepPartial type. The symptoms and workaround have changed in recent versions of TypeScript; I've reproduced the issue with [email protected] and [email protected]

[timdorr]

Do you have self-referential data/types in your state? You shouldn't, as your preloadedState needs to be serializable (by simple means, e.g. JSON.serialize, not via a special serializer) so it can be provided to the store. A circular reference would create a problem with this process, so would likely be another issue you run into even if the typings are fixed. As such, I'd almost say this is TS doing it's job and preventing a runtime error.

[hswhite33]

The type S is unconstrained, so this function is making no assertions that the state doesn't have self-referential data/types, but neither does the signature of Redux.createStore itself (I don't know of any way to model this constraint using TypeScript). In practice I don't pass any self-referential objects into the function.

The issue as I understand it is in the fact that, because S is a generic type, TypeScript goes into a stack overflow trying to compare it with the recursively defined DeepPartial<S>.

[timdorr]

It doesn't recurse infinitely, though. It will bail once it hits a non-object:

redux/index.d.ts

Line 252 in beb1fc2

[K in keyof T]?: T[K] extends object ? DeepPartial<T[K]> : T[K]

Unless you have circular references in your types, or have a very deep state tree, this isn't something you should trip in your types.

Unfortunately, we have to keep the preloadedState as partial. It may not be a complete representation of the store state once the INIT action is fired. This is particularly true for those with dynamically-added reducers. That's a common enough use case that we need to support it.

If anything, we should probably extend it to handle Arrays:

export type DeepPartial<T> = {
  [P in keyof T]?: T[P] extends Array<infer U>
    ? Array<DeepPartial<U>>
    : T[P] extends ReadonlyArray<infer U>
    ? ReadonlyArray<DeepPartial<U>>
    : DeepPartial<T[P]>
}

That won't fix the issue you're running into, but I don't think there's something we can do without breaking a greater set of users. Sorry :(

[hswhite33]

Sorry, I hadn't looked at the latest master! This bail condition actually does fix the issue I'm having.

The latest release v4.0.1 has DeepPartial defined with no bail condition:

redux/index.d.ts

Line 213 in c5d87d9

export type DeepPartial<T> = { [K in keyof T]?: DeepPartial<T[K]> }

Is there a timeline on a new release which will include this improved type definition?

[timdorr]

I'm currently at the beach, so I can look at it next week.

[val-grasley]

@timdorr Hope you had a fun time at the beach. Any chance we could get a patch with this fix?

[timdorr]

Yep, sorry. I can look into a release soon.

[val-grasley]

Thanks!

[timdorr]

Pushed out 4.0.2 now: https://github.com/reduxjs/redux/releases/tag/v4.0.2