TypeScript: HOC returned component props can not differ from HOC generic props

TypeScript Version: 3.3.0-dev.20181208

Search Terms:

  • HOC
  • react
  • higher order component

Code

import * as React from 'react';

export interface HOCProps {
  foo: number;
}

/** Remove props, that have been prefilled by the HOC */
type WithoutPrefilled<T extends HOCProps> = Pick<T, Exclude<keyof T, 'foo'>>;

function withFoo<P extends HOCProps>(WrappedComponent: React.ComponentType<P>) {
  return class SomeHOC extends React.Component<WithoutPrefilled<P>> {
    public render(): JSX.Element {
      return <WrappedComponent {...this.props} foo={0} />;
    }
  };
}

Expected behavior: No error, like with every version below 3.2.0.

Actual behavior: Throws an error highlighting the WrappedComponent in the render method.

[ts]
Type 'Readonly<{ children?: ReactNode; }> & Readonly<Pick<P, Exclude<keyof P, "foo">>> & { foo: number; }' is not assignable to type 'IntrinsicAttributes & P & { children?: ReactNode; }'.
  Type 'Readonly<{ children?: ReactNode; }> & Readonly<Pick<P, Exclude<keyof P, "foo">>> & { foo: number; }' is not assignable to type 'P'. [2322]

Additional Information

This is pretty much the same sample example used in https://github.com/Microsoft/TypeScript/issues/28720, but with the difference, that the props of the returned component differ from the generic.

Basically the HOC prefills the foo property for the WrappedComponent. Since the spreaded props are overriden by foo, I don’t want foo to be a valid property for the HOC. This does not seem to be possible anymore.

Playground Link:

Related Issues: https://github.com/Microsoft/TypeScript/issues/28720

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 78
  • Comments: 23 (3 by maintainers)

Commits related to this issue

Most upvoted comments

Starting with 3.2 the behaviour of the spread operator for generics has changed. Apparently the type of props gets erased as a negative side effect, but you can work around that by casting it back to P using {...props as P} when spreading back into the wrapped component.

@ahejlsberg The change is that we no longer erase generics in JSX (so we actually check these calls now), and roughly that Pick<P, Exclude<keyof P, "foo">> & { foo: P["foo"] } doesn’t recombine to (or get recognized as assignable to) P. It’s an unfortunate interaction with generic rest/spread, and the error we output is bad, too.

Ok here is another take from @dex157:

export interface WithFooProps {
  foo: number;
}

export function withFoo<ComponentProps>(WrappedComponent: React.ComponentType<ComponentProps & WithFooProps>) {
  return class FooHOC extends React.Component<ComponentProps> {
    public render() {
      return <WrappedComponent {...this.props} foo={0} />;
    }
  };
}

This way we don’t even have to use Omit and type inference works correctly:

interface ButtonProps {
  title: string;
}

const Button: React.ComponentType<ButtonProps> = withFoo(({title, foo}) => {
  return <button id={String(foo)}>{title}</button>
})


const App = () => {
  return <main><Button title="click me" /></main>
}

Here is a TypeScript playground to try it out.

Basically the difference in @satansdeer answer is to use type (which is not stated there explicitly) instead of interfaces

This will not work

import * as React from 'react';

export interface WithFooProps {
  foo: number;
}

interface ButtonProps extends WithFooProps {
  title: string;
}

export function withFoo<ComponentProps>(WrappedComponent: React.ComponentType<ComponentProps & WithFooProps>) {
  return (props: ComponentProps) => {
    return <WrappedComponent {...props} foo={0} />;
  }
};

const RealButton: React.FC<ButtonProps> = ({title, foo}) => {
  return <button id={String(foo)}>{title}</button>
} 

const Button = withFoo(RealButton)


const App = () => {
  return <main><Button title="click me" /></main>
}

And this will

import * as React from 'react';

export interface WithFooProps {
  foo: number;
}

type ButtonProps= {
  title: string;
} & WithFooProps

export function withFoo<ComponentProps>(WrappedComponent: React.ComponentType<ComponentProps & WithFooProps>) {
  return (props: ComponentProps) => {
    return <WrappedComponent {...props} foo={0} />;
  }
};

const RealButton: React.FC<ButtonProps> = ({title, foo}) => {
  return <button id={String(foo)}>{title}</button>
} 

const Button = withFoo(RealButton)


const App = () => {
  return <main><Button title="click me" /></main>
}

The difference is in ButtonProps

I’m kind of reviving this thread but casting is not a proper solution, it’s highly unsafe. Here’s a sample:

import React, { ComponentType } from 'react'

export type BaseProps = {
  value: string
  name: string
}

export type InjectedProps = {
  onChange: () => {}
}

export const withOnChange = <TProps extends BaseProps & InjectedProps>(
  Component: ComponentType<TProps>
) => {
  return ({ name, ...props }: Omit<TProps, keyof InjectedProps>) => {
    return <Component {...(props as TProps)} />
  }
}

This sample is totally valid even Component does not receive either onChange and name which are required props. We ship a massive bug due to this in our product today because of this. This really needs to be fixed, casting is such a bad idea and I feel like I have to use it too many times. If someone has a better workaround solution, I would be happy about it

I’ve tried to do this to avoid type assertion:

type InjectedProps = {
  foo: string
}

type PropsWithoutInjected<TBaseProps> = Omit<
  TBaseProps,
  keyof InjectedProps
>

export function withFoo<TProps extends InjectedProps>(
  WrappedComponent: React.ComponentType<
    PropsWithoutInjected<TProps> & InjectedProps
  >
) {
  return (props: PropsWithoutInjected<TProps>) => {
    return <WrappedComponent {...props} foo="bar" />
  }
}

This way the wrapped component can’t receive the injected props and TypeScript does not complain.

Here is a TypeScript playground with an example of how this HOC can be used.

I think that this issue can be closed, since the implicit types of the spread operator were changed.

This is a fully working example you can use with TS 3.5+ (or for 3.2+ use type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>)

type ShadowInjected<T1, T2> = Omit<T1, keyof T2>;

interface HOCProps {
    foo : number;
}

export const withSomething = <T,>(WrappedComponent: React.ComponentType<T>): React.FC<ShadowInjected<T, HOCProps>> => {
    return function WithSomething(props: ShadowInjected<T, HOCProps>) {
        // Do you HOC work here
        return (<WrappedComponent foo={1337} {...props as T} />);
    };
};

Of course, if you need to shadow only one property explicitly, you don’t need the ShadowInjected type and use Omit<HOCProps, "yourProperty"> instead.

Had to use <WrappedComponent {...this.props as any} inject={injected}/> to temporarily bypass the HOC props merge.

@lvkins the idea here is to force WrappedComponent to extend your HOC injected props

my case example
import React, { ComponentType } from 'react'
import { CountrySettingsFlags } from '../country-settings-flags.enum'
import { useCountries } from './countries.hook'

type WithCountriesProps = {
  countries: ReturnType<typeof useCountries>
}

function withCountries(flags: CountrySettingsFlags[] = []) {
  return function <Props extends WithCountriesProps>(Component: ComponentType<Props>) {
    return function (props: Omit<Props, keyof WithCountriesProps>) {
      const countries = useCountries(flags)
      return <Component {...props as Props} countries={countries} />
      //                          ^^^^^^^^
      // without this will also error, what is describing this issue
    }
  }
}

type TestProps = {
  the: number
  one: string
}

function Test(props: TestProps) {
  return null
}

const Wrapped = withCountries()(Test)
//                              ^^^^
// error because `TestProps` does not extend `WithCountriesProps`

const test = <Wrapped the={666} one="" />

I’m seeing the same thing as the original poster, but from version 3.1.6 to 3.2.2

I believe I’m having the exact same problem on TypeScript 3.2.2, and I’d like to share my use case to show another way this is affecting HOCs in React. In my case I have a HOC that grabs WrappedComponent’s children to render it in a different way, forwarding all props but children to WrappedComponent, resulting in the exact same error @hpohlmeyer mentioned.

Here’s a simplified (React Native) code:

import * as React from 'react';
import { ViewProps } from 'react-native';

export const withXBehavior = <P extends ViewProps>(
  WrappedComponent: React.ComponentType<P>,
): React.ComponentType<P> => (props) => {
  const { children, ...otherProps } = props;

  return (
    <WrappedComponent {...otherProps}> /* ERROR HERE */
      <React.Fragment>
        <View>
          <Text>example of HOC stuff here</Text>
        </View>
        {children}
      </React.Fragment>
    </WrappedComponent>
  );
};

Error: Type '{ children: Element; }' is not assignable to type 'P'. [2322]

This was working fine on 3.0.1 and is now giving me this error on 3.2.2 (haven’t tested on 3.1).

In my real world case I need <P extends ViewProps> to have the ability to use onLayout:

<WrappedComponent {...otherProps} onLayout={this.myFunction} />

If I forward all HOC props to WrappedComponent the error is gone, but that would prevent HOCs to change behavior of WrappedComponents.

import * as React from 'react';
import { Text, View, ViewProps } from 'react-native';

export const withXBehavior = <P extends ViewProps>(
  WrappedComponent: React.ComponentType<P>,
): React.ComponentType<P> => (props) => {
  const { children } = props;

  return (
    <WrappedComponent {...props}>
      <React.Fragment>
        <View>
          <Text>example of HOC stuff here</Text>
        </View>
        {children}
      </React.Fragment>
    </WrappedComponent>
  );
};

No errors in the above code.

@ahejlsberg The change is that we no longer erase generics in JSX (so we actually check these calls now), and roughly that Pick<P, Exclude<keyof P, "foo">> & { foo: P["foo"] } doesn’t recombine to (or get recognized as assignable to) P. It’s an unfortunate interaction with generic rest/spread, and the error we output is bad, too.

@weswigham Is this the same as https://github.com/Microsoft/TypeScript/issues/28748?