New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some existing connect calls are broken by 5.0.16 #24913
Comments
@variousauthors could you please share the versions of EDIT: the |
@variousauthors I think you're spot on with this comment
The bug is that the type definitions for redux's |
Reverting to 5.0.15 does not completely solve the issue. While 5.0.15 will compile this kind of code without warning- it still errors if you add type-checking of the props for the presentational component in the For example this will work in 5.0.15, but not 5.0.16 However- even in 5.0.15, you can't typecheck the I think this is a larger issue that has been lurking in the type mappings that @Pajn 's cleanup brought to light. |
Infered decorated typings would rely on the implicit and false assumption that decorated component props extend injected props and own props DefinitelyTyped#24922 DefinitelyTyped#24913
…ection * InjectedProps should not have to extend DecoratedProps * DecoratedProps should not have to extend InjectedProps * DecoratedProps should extend Intersection<InjectedProps, DecoratedProps> * Remaining Props should be required on the decoration output DefinitelyTyped#24913 DefinitelyTyped#24922
…ps, contravariance issue (#25228) * feat(react-redux): add strict null check * feat(react-redux): remove improper inference tests Infered decorated typings would rely on the implicit and false assumption that decorated component props extend injected props and own props #24922 #24913 * fix(react-redux): injected props and decorated component props intersection * InjectedProps should not have to extend DecoratedProps * DecoratedProps should not have to extend InjectedProps * DecoratedProps should extend Intersection<InjectedProps, DecoratedProps> * Remaining Props should be required on the decoration output #24913 #24922 * feat(react-redux): add new commiters * feat(react-redux): 2.9 keyof compatibility depends on Extract (2.8)
@types/xxxx
package and had problems.Definitions by:
inindex.d.ts
) so they can respond.The Issue(s)
Hello! I've just updated to
5.0.16
and immediately encountered some trouble using these new typings in my existing project. Here are some relevant versions numbers:A Typical Container does not Compile
Here is some code that I think should compile (and which did compile prior to
5.0.16
and which compiles again if we set the version back to5.0.15
):Normally I would go on to use the container like this,
However, with this code, using the latest
@types/react-redux
at5.0.16
and typescript at2.8.1
I instead get the following error:Inspecting the changes introduced in
5.0.16
, it feels like the type system is upset becauseconnector
has typeInferableComponentEnhancerWithProps<IPropsFromState & IPropsFromParent, IPropsFromParent>
which means that it is expecting the first argument to be of typeIPropsFromState & IPropsFromParent
. My base component is missing the propertyreportType
.For example, if I write this:
These minimal examples fail. The first fails for the same reason as the code above, with the same opaque error message. The second fails because, clearly,
IExampleProps
does not have a propertyreportType: ReportType
so we can't assignIExampleProps
toP
. It is missingreportType
. I suspect this is, under the hood, what is causing the first example to fail.It seems like after
5.0.16
containers are not allowed to add new properties to the interfaces of their wrapped components? This is what I see, looking at the code.It is part of my normal workflow to define components in terms of only what properties they need, and then to extend those components with HOCs that define a new interface and provide the component its properties via the redux store. In some cases the new interface is a subset of the wrapped component's interface, but in other cases it may not be. In the case above, the new interface has an additional property
reportType
which the caller will use but that the wrapped component will never see.A More Idiosyncratic Container does not Compile
I have an another example of a technique I use that is broken by this change:
Suppose we have two simple components,
I want to build an HOC that provides the
date
for these components without needing to know anything about thename
property at all. This way I can make, for example, a NameProvider and a DateProvider, and compose them like this:NameProvider(DateProvider(BaseComponent))
or like thisDateProvider(NameProvider(BaseComponent))
, something which I normally can't do with a well typed component enhancer because of the need to specifyTOwnProps
.This new interface agnostic component enhancer is used as follows:
So the
DateProvider
HOC is able to augment a component without being fully aware of that component's interface. It only needs to know that the given component will be capable of accepting the props that it provides.With
5.0.16
this no longer works, instead I get the following error message:Playing around, I've noticed the following:
When we explicitly type the connector, everything works?
That's it! Thanks for reading ;) for now I have set my
@types/react-redux
to a previous version and all is well.The text was updated successfully, but these errors were encountered: