Function Components vs React.FC in TypeScript: A Civil Discourse

Understanding the evolution of TypeScript typing in React components

Function Components vs React.FC in TypeScript: A Civil Discourse

React and TypeScript walk into a project together. TypeScript says, "I'll handle the types." React says, "I'll handle the rendering." And somewhere along the way, someone asks:

Should we use React.FC, or just type the function directly?

It's a reasonable question. At a glance, React.FC looks polished, official—even sophisticated. Like it might pour your code a glass of wine and say "Let's make this component elegant." But beneath the surface, it carries some baggage that modern TypeScript has mostly outgrown.

Let's take a closer look.

The Two Styles

The Plain Function Component

type Props = { title: string };

function MyComponent({ title }: Props) {
  return <h1>{title}</h1>;
}

Clean, clear, and easy to understand. Like a black coffee: no frills, just gets the job done.

Or, if you prefer arrow functions:

const MyComponent = ({ title }: Props) => {
  return <h1>{title}</h1>;
};

Both are valid, readable, and well-aligned with current best practices.

The React.FC Variant

import { FC } from 'react';

type Props = { title: string };

const MyComponent: FC<Props> = ({ title }) => {
  return <h1>{title}</h1>;
};

This version wraps the component with a generic type. It looks more "official," and if you've recently discovered TypeScript's utility types, it might feel like a natural fit—like you've just unlocked a secret club. But sometimes, secret clubs come with fine print.

What React.FC Actually Does

React.FC (short for React.FunctionComponent) is a helper type that describes a function component. It offers a few default behaviors:

  • It includes the children prop by default, whether you want it or not.
  • It can occasionally enhance autocomplete in certain editors.
  • It can make the return type of the function a bit more explicit, though that rarely matters in practice.

These are modest conveniences, and in earlier days of React + TypeScript, they were more useful. But times have changed, and today, these "features" often get in the way more than they help.

Why It's Falling Out of Favor

You could say that React.FC is the cargo pants of TypeScript—lots of pockets, most of them unused.

  1. Implicit children

Every component gets a children prop whether it wants one or not. This can lead to confusing bugs when developers assume children are valid just because the type says so. (Spoiler: they might not be.)

  1. Awkward with generics

When your component needs to use generic types, React.FC tends to make things messier, not cleaner. The syntax becomes clunky, and TypeScript gets less helpful, not more.

  1. Verbosity without clarity

Writing const MyComponent: FC<Props> is longer, and arguably more obscure, than simply typing the props directly.

  1. No longer necessary

The original reasons for using React.FC—editor support, JSX inference—have mostly been addressed by TypeScript improvements. What was once a practical workaround is now just legacy style.

A Side-by-Side Comparison

Feature function Component() const Component: FC
Includes children? Only if declared Always included
Supports generics? Gracefully Not without effort
Verbose? Minimal Noticeably more
Editor support? Sufficient Slightly better in specific cases
Recommended? Yes Not anymore

The Recommended Approach

The consensus in the community is simple: type your props directly. If you want your component to accept children, say so. If you don't, it won't. That's the kind of honesty your future self will appreciate.

type Props = {
  title: string;
  children?: React.ReactNode;
};

const MyComponent = ({ title, children }: Props) => (
  <div>
    <h1>{title}</h1>
    {children}
  </div>
);

It's explicit. It's maintainable. And it doesn't pretend your component handles children when it doesn't.

Are There Situations Where FC Still Makes Sense?

Occasionally. If you're working in a legacy codebase that leans heavily on React.FC, maintaining consistency might matter more than rewriting everything. If you're quickly mocking up components and don't want to worry about typing children, FC can still be a shortcut.

But in general, those are the exceptions that prove the rule.

In Closing

React.FC isn't wrong. It's just no longer necessary. Modern TypeScript has made typing React components simpler and more predictable without it.

So next time you reach for FC, pause and consider whether you're adding value—or just extra layers. More often than not, a plain typed function will serve you better.

In software—as in life—clarity beats cleverness. And fewer surprises usually means fewer regrets.

Categories