FunctionComponent and ComponentClass are not compatible with LibraryManagedAttributes

[Ferdy Budhidharma]

Annotating functions and classes with FunctionComponent and ComponentClass breaks LibraryManagedAttributes due to the static defaultProps property on those interfaces being set to optional.

import { FunctionComponent, ComponentClass, Component } from 'react'

export interface Props {
  foo: string
  bar?: boolean
}

const TestFunction: FunctionComponent<Props> = props => <div />
TestFunction.defaultProps = {
  foo: '',
}

const TestClass: ComponentClass<Props> = class TestClass extends Component<Props> {
  static defaultProps = {
    foo: '',
  }

  render() {
    return <div />
  }
}

// type is never
type TestDefaultProps = typeof TestFunction extends { defaultProps: infer D } ? D : never
type TestClassDefaultProps = typeof TestClass extends { defaultProps: infer D } ? D : never

// type is Props because typeof Test does not extend { defaultProps } but rather { defaultProps? }
type TestManagedProps = JSX.LibraryManagedAttributes<typeof TestFunction, Props>
type TestClassManagedProps = JSX.LibraryManagedAttributes<typeof TestClass, Props>

This causes defaultProps to be completely ignored by JSX.LibraryManagedAttributes. We should probably remove it as a recommendation from the cheat sheet for now.

[Ferdy Budhidharma]

Some more context on the issue. I even forgot about it... shame on me. DefinitelyTyped/DefinitelyTyped#30695

[swyx.io]

thanks - i’ll update accordingly. why is it considered a bad idea to have implicitly typed children? i thought that was a major benefit of using React.FC.

as a side note - i dont find myself ever using defaultProps for function components as i can assign when i destructure...

[Sebastian Silbermann]

as a side note - i dont find myself ever using defaultProps for function components as i can assign when i destructure...

1. Makes parsing a component easier: You don't have to look through the function body to know what the default props are. Even more so you don't have to care about the specific component implementation. Just scan for defaultProps and ignore whether it is a class, function, forwardRef etc.
2. tools like react-docgen only understand defaultProps Actually I'm not sure how good react-docgen is in this regard. Does it only know function ({ foo = 'default' }) or can it find the default value reliably?

[swyx.io]

i've put in something quick to reflect this info. It's not clear to me if we should just blanket advise against using React.FC altogether, that feels like a very strong recommendation that we'd have to justify just because of defaultProps. I'm open to it, but simply havent done it yet. Happy to hear your thoughts.

[Sebastian Silbermann]

It's not clear to me if we should just blanket advise against using React.FC altogether

I wouldn't do that either. I think it's perfectly fine to explain the drawbacks of

explicit annotations on function expressions:

• -no defaultProps
• +explicit type annotation (helps with some gotchas concerning return types of function components)
• -no additional statics
• -no generic props

function declarations:

• +defaultProps in ts >= 3.1
• no implicit children
• -needs explicit return type to catch wrong return type
• +additional statics
• +generic props

Personally I don't like implicit children anyway. Not all of my components handle children. I would hope typescript would recognize some day that <Foo>bar</Foo> is equivalent to <Foo children="bar" /> and report an error on both call sites if the props of Foo don't define a children property.

[Ferdy Budhidharma]

If I could rewrite react types implicit children would be removed. It causes a lot more problems and was only placed there for convenience.

I always explicitly include children in my props interfaces anyway when I do support them.

[swyx.io]

cool cool i'll incorporate more or less what @eps1lon suggested. makes sense

[Sebastian Silbermann]

as a side note - i dont find myself ever using defaultProps for function components as i can assign when i destructure...

@sw-yx Well looks like you're not the only one: Deprecate defaultProps on function components

[Adrien Denat]

That's great to know that React actually think about deprecating defaultProps. Could we come up with a pattern that works and does not use defaultProps?

[swyx.io]

i mean.. destructure and assign defaults?

const TestFunction: FunctionComponent<Props> = { foo = "bar" } => <div>{foo}</div>

[Adrien Denat]

I was thinking more of something along these lines:

const defaultProps = {
  foo: 'bar',
};

type Props = typeof defaultProps & {
  optional?: string
};

export const TestFunction: FC<Props> = props => {
  const { foo } = {
    ...defaultProps,
    ...props,
  };
  return (
    <div>{foo}</div>
  );
};

As that's the pattern that is currently advised in the doc.

[Ferdy Budhidharma]

Default values inside parameters (and when destructured) are better understood by the compiler. It will allow you to not have to hack together the props interface. The compiler knows it will always be defined inside the implementation but optional when consumed.

[Adrien Denat]

Right.
You would also have to define your type interface props as optional for all the ones that have a default value. Since you're not using defaultProps anymore.

[Reinis Ivanovs]

{ foo = "bar" } => <div>{foo}</div> isn't valid syntax, ({ foo = "bar" }) is, and it would also require = {} at the end or else the caller would need to provide an empty object to use the defaults. So:

const TestFunction: FunctionComponent<Props> = ({ foo = "bar" } = {}) => <div>{foo}</div>

Also, there isn't really much reason to use FC with TS and function components, as .defaultProps, .propTypes and .displayName have better alternatives, and .contextTypes is a legacy feature, so, given the nullable .children typing issue FC has, it probably should just be ({ foo = "bar" }: Props = {}).

[swyx.io]

yep y'all know what i mean

[swyx.io]

going to close this now since it seems we havent had much complaints on this front after Seb's initial recommendations

[Remi Vledder]

@slikts

"...as .defaultProps, .propTypes and .displayName have better alternatives,..."

I'm having trouble finding the alternative to default props for a functional component.

In the Readme the link to Martin Hochels article mentions you can use type inference for a class component. But that does not work for an FC component. In an earlier article by the same author (from 2018) he mentions a custom getProps function. That covers all the use-cases as explained in the article, but it seems a bit perculiar.

Using prop destructuring gives a linting error (require-default-props). Should this be ignored?

Is that the way to go? An example would help.

[Reinis Ivanovs]

The linter error should be ignored or turned off, because destructuring and default values already achieves the same as .defaultProps. The linter errors are just rules of thumb that are contextual, and this specific rule doesn't apply in this case.

[Dariusz Rzepka]

We found a little bit of casting here to be a good compromise. Obviously, if you don't need defaultProps, the best is to use what Sebastian has suggested (we need this to generate docs).

import React from 'react';
import PropTypes from 'prop-types';

export type MyComponentProps = {
    optionalButDefaulted?: string;
};

const defaultProps = {
    optionalButDefaulted: 'optionalButDefaulted',
};

export const MyComponent = (props: MyComponentProps) => {
    const { optionalButDefaulted } = props as MyComponentProps &
        typeof defaultProps;

    return <div>The string length: {optionalButDefaulted.length}</div>;
};

export const myComponentPropTypes: React.WeakValidationMap<MyComponentProps> = {
    optionalButDefaulted: PropTypes.string,
};

MyComponent.propTypes = myComponentPropTypes;
MyComponent.defaultProps = defaultProps;
MyComponent.displayName = 'MyComponent';