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

If your components Props interface extends another interface, defaultProps still doesn't work in TS3 #61

Closed
gausie opened this issue Jan 4, 2019 · 12 comments · Fixed by #275
Labels
wontfix This will not be worked on

Comments

@gausie
Copy link

gausie commented Jan 4, 2019

No description provided.

@swyxio
Copy link
Collaborator

swyxio commented Jan 5, 2019

ok what do you recommend i put in the cheatsheet?

@gausie
Copy link
Author

gausie commented Jan 5, 2019 via email

@swyxio
Copy link
Collaborator

swyxio commented Jan 6, 2019

have you reported this as a bug? (is this a bug? i think it is?)

@gausie
Copy link
Author

gausie commented Jan 7, 2019 via email

@swyxio
Copy link
Collaborator

swyxio commented Jan 8, 2019

just try :) good luck

@ferdaber
Copy link
Collaborator

Do you have a code example for this? I would also open this as an issue in the DefinitelyTyped repo instead so the other React types maintainers can take a look.

@infctr
Copy link

infctr commented Feb 18, 2019

I guess it goes like

type ComponentProps<T> = T extends React.ComponentType<infer P> | React.Component<infer P>
  ? JSX.LibraryManagedAttributes<T, P>
  : never;

interface IProps {
  name: string;
}

interface IDefaultProps {
  age: number;
}

const GreetComponent = ({ name, age }: IProps & IDefaultProps) => (
  <div>{`Hello, my name is ${name}, ${age}`}</div>
);

const defaultProps: IDefaultProps = {
  age: 25,
};

GreetComponent.defaultProps = defaultProps;

// later

const TestComponent = (props: ComponentProps<typeof GreetComponent>) => {
  return (
    <div> <h1 /> </div>
  );
};

const el = <TestComponent name="foo" />;

@swyxio
Copy link
Collaborator

swyxio commented Feb 20, 2019

thanks for the input @infctr! i dont quite see the point of TestComponent.

  • if i replace your impl of ComponentProps with the official one React.ComponentProps, i see that TestComponent errors because of the missing age default prop.
  • if i then add TestComponent.defaultProps = defaultProps; it typechecks.

this seems correct behavior.

@gausie, can we please see an example that you expect to work? otherwise its very hard to discuss.

@infctr
Copy link

infctr commented Feb 20, 2019

@sw-yx My point is (and that's my understanding of @gausie problem)

type Props = React.ComponentProps(typeof GreetComponent) // all props are required

type Props = ComponentProps<typeof GreetComponent> // using helper, defaulted props are optional

Extracting props with JSX.LibraryManagedAttributes is more in line with the old practice marking default props as optional on an interface like interface Props extends Partial<DefaultProps> { /* ... */ } and using it later.

Consdider this

interface Props extends ComponentProps<typeof GreetComponent> {
  title: string;
}

const TestComponent = ({ title, ...props }: Props) => {
  return (
    <>
      <h1>{title}</h1>
      <GreetComponent {...props} />
    </>
  );
};

// age is optional on an inner component's props interface
const el = <TestComponent name="Johnny 5" title="foo" />; 

Just thought it was worth mentioning as it was not immediately obvious

@ferdaber
Copy link
Collaborator

That's correct. There are valid use cases for extracting both the inner props of a component, or the apparent props (with JSX.LibraryManagedAttributes). The built-in React types only take care of the first case.

@swyxio
Copy link
Collaborator

swyxio commented Feb 20, 2019

hoo boy. ok. thank you

@stale
Copy link

stale bot commented Aug 20, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants