为什么 React.FunctionComponenent 优于传统的函数定义？

Question

I've always defined React components (with typescript) as:

function MyComponent(props: PropsType): React.ReactElement | null {
    //...
}

Online I see a lot of examples like:

const MyComponent: React.FC = (props: PropsType) => {
    //...
}

I understand they are pretty much the same, but what is the preferred convention in the Typescript community?

Answer 1

Quoting React-Typescript Cheatsheet on Github

You can also write components with React.FunctionComponent (or the shorthand React.FC ):

const App: React.FC<{ message: string }> = ({ message }) => (  
  <div>{message}</div>
); 

Some differences from the "normal function" version:

• It provides typechecking and autocomplete for static properties like displayName , propTypes , and defaultProps - However , there are currently known issues using defaultProps with React.FunctionComponent . See this issue for details
• It provides an implicit definition of children (see below) - however there are some issues with the implicit children type (egDefinitelyTyped#33006 ), and it might considered better style to be explicit about components that consume children , anyway.

const Title: React.FunctionComponent<{ title: string }> = ({  
children, title }) => <div title={title}>{children}</div>;

• In the future , it may automatically mark props as readonly , though that's a moot point if the props object is destructured in the constructor.

• React.FunctionComponent is explicit about the return type, while the normal function version is implicit (or else needs additional annotation).

In most cases it makes very little difference which syntax is used, but the React.FC syntax is slightly more verbose without providing clear advantage, so precedence was given to the "normal function" syntax.

Answer 2

In addition to Boy With Silver Wings answer - The core advantage is that the arrow function expression component ( const Foo () => <div>Hello</div> ) itself could be typed:

const Foo: YourOwnTypeAliasOrInterface = () => <div>Hello</div>

React.FC implements as being said a couple of types for you (children, or possible return types). You can't do that with your named function component:

function Foo<YourOwnTypeAliasOrInterface>() { // this does not work!! (Only with generics)
  return <div>Hello</div>
}

TL;TR with React.FunctionalComponent you simply have to type less, because types such as return type and children is already defined.

type FooProps = {
  title: string;
} & React.FC // <-- intersection type, so it has FooProps and React.FC typings

const Foo: FooProps = ({ children, title }) => { ... }

Answer 3

Create React App recently dropped FC / FunctionComponent type usage from the TypeScript template.

---

Downsides of FC :

• implicit optional children - better define your props API explicitely

• no generic component creation possible

• no need to have explicit ReactElement | null ReactElement | null return type, which in addition is not accurate ; it can be 1) better inferred automatically by TS or 2) set explicitely

• FC is just a wrapper for statics like contextTypes , propTypes , etc. which aren't needed in most cases

• doesn't work well with defaultProps (Note: JS default args should be preferred anyway)

• no need to remember "magic" types - just use functions for components

• doesn't make your code (much) leaner

---

So in summary, I would rather state the opposite: plain (arrow) functions > React.FC .