Skip to content
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

Type parameter on higher-order-component doesn't seem to work #28720

Closed
MLoughry opened this issue Nov 28, 2018 · 2 comments
Closed

Type parameter on higher-order-component doesn't seem to work #28720

MLoughry opened this issue Nov 28, 2018 · 2 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@MLoughry
Copy link

TypeScript Version: 3.2.0-rc, 9319ea4

Search Terms:
higher order component, React, type parameter

Code

import * as React from 'react';

export interface ComponentProps {
    foo: number;
}

export default <P extends ComponentProps>(WrappedComponent: React.ComponentType<P>) => {
    return class SomeHOC extends React.Component<P, {}> {
        render() {
            return <WrappedComponent foo={0} />;
        }
    };
}

Expected behavior:
No error (as in 3.1.6)

Actual behavior:

src/wrappedComponent.tsx:10:21 - error TS2322: Type '{ foo: number; }' is not assignable to type 'IntrinsicAttributes & P & { children?: ReactNode; }'.
  Property 'foo' does not exist on type 'IntrinsicAttributes & P & { children?: ReactNode; }'.

10             return <WrappedComponent foo={0} />;

Playground Link:

Related Issues:
Possibly #28636, #28647, #28719

@weswigham
Copy link
Member

weswigham commented Nov 29, 2018

We corrected & tightened up our checking of generics in jsx - we had a nasty habit of erasing them before.

You're declaring that your WrappedComponent takes a P extends ComponentProps, but are only providing a ComponentProps to the WrappedComponent when its type states that you must provide a P. Usually you'd do this by spreading the input props to SomeHOC into your WrappedComponent tag.

@weswigham weswigham added the Question An issue which isn't directly actionable in code label Nov 29, 2018
@MLoughry
Copy link
Author

Got it. The actual (non-example) code was using some cached props in the state, of type ComponentProps. By making the state itself similarly generic, it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

2 participants