Rethinking TypeScript Practices: The Downside of React.FC

In recent years, using TypeScript with React has become increasingly popular. TypeScript adds static typing to JavaScript, making it more robust and developer-friendly. One of TypeScript's constructs for React components is React.FC, which stands for "React Function Component". This type definition has been widely used, but there's a new school of thought that suggests avoiding it. Let's discuss why.

What is React.FC?

In TypeScript, React.FC or React.FunctionComponent is a type that represents a function component. It can be used like this:

const MyComponent: React.FC = () => {
    return <div>My Component</div>;
};

The Downside of React.FC

While React.FC seems convenient, it has certain downsides that might make you reconsider its usage. These were highlighted in a Pull Request on the Create React App repository back in 2019.

Implicit Definition of Children

When you use React.FC, it implicitly includes children in the props, even if you don't need them. It means all components accept children as a prop. This can lead to unwanted renderings in your component and is not caught by TypeScript due to React.FC.

const App: React.FC = () => <div>Hello World</div>;

// Even though `App` doesn't expect children, it will still render them.
const Example = () => (
  <App>
    <div>Unwanted children</div>
  </App>
);

The Example component will render "Unwanted children" even though App is not designed to accept children.

Doesn't Support Generics

React.FC does not preserve unresolved generics, so you can't create a generic component like this one that accepts a prop of any type and a callback function to handle the prop:

type GenericComponentProps<T> = {
  prop: T;
  callback: (t: T) => void;
}

// The following will cause an error
const GenericComponent: React.FC<GenericComponentProps> = ({ prop, callback }) => {
  // Some component logic here
};

Makes "component as namespace pattern" more awkward

This pattern, which is quite popular, allows a component to be used as a namespace for related components. Using React.FC makes this awkward:

type SelectProps = { /* ... */ };
type ItemProps = { /* ... */ };

// With React.FC
const Select: React.FC<SelectProps> & { Item: React.FC<ItemProps> } = (props) => {/* ... */ }
Select.Item = (props) => { /*...*/ }

// Without React.FC
const Select = (props: SelectProps) => {/* ... */}
Select.Item = (props: ItemProps) => { /*...*/ }

Doesn't Work Correctly with defaultProps

The defaultProps mechanism in React is used to define default values for props in a component. It is useful when you want some props to have a default value, but also want to allow consumers of your component to override these defaults.

The issue with React.FC arises when we combine TypeScript and defaultProps.

type ComponentProps = { name: string; }

const Component: React.FC<ComponentProps> = ({ name }) => (<div>{name.toUpperCase()}</div>);

Component.defaultProps = { name: "John" };

// usage
<Component /> // TypeScript error: Property 'name' is missing...

In this example, TypeScript considers name as required and doesn't acknowledge that defaultProps provides a default value for it. So, when we try to use <Component /> without providing a name prop, TypeScript will give an error, even though this should be valid due to the defaultProps.

The Alternative to React.FC

A cleaner way to define function components in TypeScript is to type the props and the function's return value directly:

type MyComponentProps = {
  /* define your prop types here */
};

const MyComponent = (props: MyComponentProps): JSX.Element => {
  /* ... */
};

This alternative doesn't have the downsides associated with React.FC. It doesn't implicitly include children, supports generics, allows the "component as namespace" pattern, and works correctly with defaultProps.

Conclusion

Navigating the realm of TypeScript with React can feel a bit like deciphering a new language. On our journey, we initially encounter React.FC, a seemingly helpful guide that promises to make our path smoother. However, as we dig deeper and our understanding grows, we come to recognize its limitations - its automatic inclusion of children props, the lack of generics support, its awkward relationship with the 'component as namespace' pattern, and its deficiency in handling defaultProps effectively.

In software development, each tool we use, each methodology we adopt, is in service of creating efficient, reliable, and maintainable code. We owe it to ourselves and to the robust applications we aim to build, to select the most reliable and beneficial practices.

Instead of React.FC, a more flexible and robust alternative presents itself—directly typing the component function and its props. This approach doesn't suffer from the constraints of React.FC and supports our components in all their various forms and functionalities.

Let's remember, the landscape of technology is always shifting. The tools and approaches that seemed infallible yesterday might be revealed as imperfect today. This doesn't negate their prior value but instead underscores the evolutionary nature of software development. The shift away from React.FC towards more explicit typing isn't a dismissal, but rather a symbol of our growing understanding and maturity in using TypeScript with React.

As we continue our journey through the diverse landscape of TypeScript and React, let's stay adaptable, keep our knowledge updated, and strive for the practices that enable us to build better, more reliable software. Even if it means parting ways with some old habits, the benefits gained from this evolution will be worth the effort. Let the dance of development continue!