How should I declare a Stateless Functional Component with Typescript in React?

Question

I've seen two ways of declaring a SFC in React with Typescript, which are these two:

import * as React from 'react'

interface Props {
  message: string
}

const Component = (props: Props) => {
  const { message } = props
  return (
    <div>{message}</div>
  )
}

export default Component

and:

import * as React from 'react'

interface Props {
  message: string
}

const Component: React.StatelessComponent<Props> = props => {
  const { message } = props
  return (
    <div>{message}</div>
  )
}

export default Component

From this question I see that with the second way you can omit children from your interface if you are using it in your component.

Are there any more differences? Which one is the preferred one and why?

Answer 1

The definition for React.StatelessComponent<T> is:

interface StatelessComponent<P> {
    (props: P & { children?: ReactNode }, context?: any): ReactElement<any>;
    propTypes?: ValidationMap<P>;
    contextTypes?: ValidationMap<any>;
    defaultProps?: Partial<P>;
    displayName?: string;
}

In your for snippet Component is inferred by the compiler to be:

(props: Props): ReactElement<any>

(or something similar).

If you write the first one like this:

const Component = (props: Props & { children?: ReactNode }) => {
    ...
}

You are pretty much getting the same thing (as long as you don't use the properties of Component)

Answer 2

When you declare that const Component: React.StatelessComponent<Props> You basically declaring what this function gets, and what it returns:

interface StatelessComponent<P> { (props: P ... ): ReactElement<any>;

So for readability, I would actually do:

const Component = (props: Props): JSX.Element => {

Because here the developer that looks into this code don't need to know what is the interface of StatelessComponent - he can just read what goes in and what goes out.

And basically, it is all a big:

const Component: React.StatelessComponent<Props> = (props: IProps): JSX.Element =>

Answer 3

UPDATE: read the final part for React Hooks update

The preferred one is React.SFC (Before React 16.7):

import * as React from 'react'

interface Props {
  message: string
}

const MyComponent: React.SFC<Props> = props => {
  const { message } = props
  return (
    <div>{message}</div>
  )
}

export default MyComponent

Why?

SFC stands for Stateless Functional Component.

About your 1st examle, given it was done "manually" it has some problems. For example, it cannot point to props.children, because it wasn't defined in your interface. You don't have this problem with React.SFC.

(Note that Stateless Functional Component, Functional Component and Stateless Component seem to mean the same but actually are 3 different things (Functional Components vs. Stateless Functional Components vs. Stateless Components)

Given you're looking for a Stateless Functional Component, React.SFC is exactly the way to go. Other options may not be functional or may not be stateles, or may not fulfill a correct Component interface (like your manual example).

EDIT: Update since React Hooks arrived:

Since React hooks arrived, function components can also have internal state, so the disctintion is smaller now. The preferred way for function components (state or stateless) now is React.FunctionComponent

const MyComponent: React.FunctionComponent<Props> = props => {
  // ... Same as above
}

Cheers, from La Paz, Bolivia.

Answer 4

At the time of this writing, the trend for writing Functional React Components are:

• Do not use React.StatelessComponent, React.SFC (Both are deprecated)
• Omit React.FunctionComponent and React.FC (For reasons outlined below)

So the recommended style could look like:

import * as React from 'react'

interface Props {
  message: string
}

const Component = ({message}:Props) => {
  return (
    <div>{message}</div>
  )
}

export default Component

The reasoning for omitting React.FC and React.FunctionComponent can be traced to the removal from the CRA Typescript Template.

Additional thoughts can be found on Kent C Dodd's blog

In summary, the reason for removal of React.FC (and React.FunctionComponent) is the usage provides little benefit and introduces possible problems. To quote Mr. Dodds:

[Omitting the usage] doesn't have any of the shortcomings of React.FC and it's no more complicated than typing the arguments to a regular function.

A very short summary of issues using React.FC

1. Components accepts a children prop even if you don't use it
2. Generics are not supported
3. Makes "component as namespace pattern" more awkward.
4. Default Props do not work correctly
5. It's as long, or longer than the alternative