React.FCを使うべきではない理由

はじめに

先日、Gusto のエンジニアリングブログに The Journey to a Safer Frontend: Why We Removed React.FC という記事が公開されていました。

この記事では、数千ものコンポーネントで使われていた React.FC をすべて除去し、通常の関数コンポーネントに移行した経緯が語られています。

「React.FC は避けるべき」という話は以前からありましたが、なぜこれほど大規模な移行が行われたのでしょうか。本記事では、React.FC が抱える具体的な問題点をコードで検証し、現在の推奨される書き方について整理します。

React.FC とは

React.FC（React.FunctionComponent）は、TypeScript で関数コンポーネントに型を付けるためのインターフェースです。

// React.FC を使った書き方
const Card: React.FC<CardProps> = ({ title }) => {
  return <div>{title}</div>;
};

// 通常の関数コンポーネント
const Card = ({ title }: CardProps) => {
  return <div>{title}</div>;
};

一見するとどちらでも大きな差はないように見えますが、型チェックの挙動に重要な違いがあります。

問題1：余剰プロパティチェックが効かない → 未使用の Props が残りやすい

2026/02/24 訂正: 初版では「余剰プロパティチェック（Excess Property Check）が効かなくなる」と記載していましたが、これは Gusto の元記事の内容と食い違っていました。以下、Gusto の記事の趣旨に沿い、かつ検証した結果に基づいて訂正します。

余剰プロパティチェック（JSX で定義されていない Props を渡した場合のエラー検出）については、@types/react v17・v18・v19 + TypeScript 5.9 で検証した結果、React.FC でも通常の関数でも同様に正常に機能することを確認しました。

以下のように、ButtonProps に定義されていない color というプロパティを渡すケースを考えます。

通常の関数であれば、TypeScript の「余剰プロパティチェック（Excess Property Check）」によって即座にエラーになります。しかし、React.FC は内部で Props を他の型と交差させているため、このチェックが弱まることがあります。

Gusto の記事で指摘されていた問題

Gusto の記事（「The Moment It Clicked」の章）では、以下のコード例が示されています。

// With React.FC — no warning
const Example: React.FC<{ used: string; unused: string }> = ({ used }) => {
  return <div>{used}</div>;
};

// Without React.FC — correct warning
const Example = (
  { used }: { used: string; unused: string }
): React.ReactNode => {
  return <div>{used}</div>;
};

Props の型に unused というプロパティが定義されているが、コンポーネントの実装では destructure されていない（使われていない）というケースです。Gusto は「React.FC ではこの警告が出ないが、通常の関数では出る」と主張しています。

追加検証

この Gusto の記事のコード例を @types/react v18 + TypeScript 5.9（noUnusedLocals: true, noUnusedParameters: true）で検証したところ、React.FC でも通常の関数でも、どちらもこの「未使用 Props」に対する警告は出ませんでした。TypeScript コンパイラ（tsc）は、型に定義されているが destructure されていないプロパティを「未使用」として検出しません。Gusto の環境では ESLint のルール（@typescript-eslint/no-unused-vars 等）が関係していた可能性があります。

Gusto の記事では、この移行をきっかけに「隠れていた未使用の Props」を大量に発見・除去したと報告されていますが、それが tsc の挙動差によるものなのか、ESLint 等のツールや移行作業に伴うコードレビューによるものなのかは判別できませんでした。

問題2：暗黙の children（React 18 未満）

これは古いプロジェクトで特に顕著な問題ですが、React 18 より前の React.FC には、定義しなくても自動的に children が含まれていました。

// React 17 以前の挙動
const Banner: React.FC<{ message: string }> = ({ message }) => {
  return <div>{message}</div>;
};

// children を受け取る意図がないのに、エラーにならない
<Banner message="hello">
  <span>この子要素は無視されますが、型エラーになりません</span>
</Banner>

現在の @types/react v18 では修正されていますが、古い環境のまま運用されているプロジェクトでは、意図しない children の注入を許してしまうリスクがあります。

問題3：defaultProps とジェネリクスの制約

モダンな React 開発において、React.FC は以下の場面で不便さを感じさせます。

• defaultProps の推論: ES6 のデフォルト引数（{ title = "Default" }）を使えば型推論が効きますが、React.FC と defaultProps を組み合わせると型定義が複雑になりがちです。
• ジェネリクス: リストコンポーネントのように、外部から型を注入したい場合に React.FC では対応できません。

2026/02/24 訂正: defaultProps について、初版では「型定義が複雑になりがち」と記載していましたが、より正確に修正します。

• React.FC + defaultProps
  • required な Props を JSX で省略可能にできない という問題がある（@types/react v17・v18 で確認）。
• 通常の関数コンポーネント
  • defaultProps で指定した Props は省略可能として正しく推論される。

※ ただし、React 19 では defaultProps が React.FC の型定義から完全に削除されており（TS2339: Property 'defaultProps' does not exist on type 'FC<Props>'）、そもそも React.FC に対して defaultProps を設定すること自体が型エラーになる。現在は ES6 のデフォルト引数を使うのが推奨。

// ✕ React.FC ではジェネリクスを定義できない
const List: React.FC<ListProps<T>> = ...

// ◯ 通常の関数なら自然に書ける
function List<T>({ items, renderItem }: ListProps<T>) {
  return <ul>{items.map(renderItem)}</ul>;
}

問題4：render prop への代入が型エラーになる（React 19）

@types/react@19 では、Server Component 対応のため React.FC の戻り値型が ReactNode | Promise<ReactNode> に変更されました。一方、ReactNode が受け入れる Promise は Promise<AwaitedReactNode>（ReactNode から再帰的な Promise を除いた型）です。

つまり、Promise<ReactNode> ≠ Promise<AwaitedReactNode> となるため、React.FC の戻り値型は ReactNode に代入できなくなりました。

これが実際に影響するのは、render prop を関数型 (props: P) => ReactNode で受け取る設計です。

interface ListProps {
  items: string[];
  render: (props: { name: string }) => React.ReactNode;
}

// 通常の関数 → ◯
const ItemNormal = ({ name }: { name: string }): React.ReactNode => {
  return <span>{name}</span>;
};
<List items={["x"]} render={ItemNormal} /> // 問題なし


// React.FC → 型エラー
const ItemFC: React.FC<{ name: string }> = ({ name }) => {
  return <span>{name}</span>;
};
<List items={["x"]} render={ItemFC} />
// TS2322: Type 'FC<{ name: string }>' is not assignable to
//   type '(props: { name: string }) => ReactNode'.
//   Type 'ReactNode | Promise<ReactNode>' is not assignable to type 'ReactNode'.

インラインで書く場合は問題にならない

render prop をインラインのアロー関数で書く場合、戻り値型は推論されるためこの問題は発生しません。

// インライン → 問題なし（戻り値型が推論される）
<List items={["x"]} render={({ name }) => <span>{name}</span>} />

描画ロジックが複雑になり、コンポーネントとして外出しする際に React.FC で型を付けると、この問題に遭遇し得ます。

この挙動は筆者の環境（@types/react@19.2.14 + TypeScript 5.9.3）で確認したものです。@types/react の型定義は今後変更される可能性があります。

※ Render Props パターン自体は、モダンな React ではカスタムフックに置き換わるケースが多く、以前ほど一般的ではありません（React 公式ドキュメント）。ただし、一部のライブラリでは依然として使われているパターンです。

補足

この型エラーは React.FC を使っている場合にのみ発生します。通常の関数コンポーネントで戻り値を : React.ReactNode と明示していれば、render prop への代入で問題は起きません。

ただし、この型エラーを「問題」と捉えるかどうかには議論の余地があります。

上述のとおり、FC の戻り値型に Promise<ReactNode> が含まれるようになったのは、Server Component（async component）をサポートするためです。FC はコンポーネント型として async component も包含する必要があるため、この変更自体は合理的です。

一方、render prop は (props: P) => ReactNode という関数型で定義されます。render prop に渡す関数は render(props) のように直接呼び出されるものであり、<Component /> のように JSX で使われるコンポーネントとは概念的に別物です。この観点からすると、render prop に渡す関数を FC で型付けすること自体がそもそも概念の混同であり、React 19 で両者が型として区別されるようになったことで、その混同が型エラーとして顕在化したという見方もあります。

いずれの立場をとるにせよ、通常の関数コンポーネントで戻り値を : React.ReactNode と明示していれば、この議論自体を気にする必要がなくなります。個人的には、そのシンプルさが React.FC を避ける理由になるかなと感じています。

React.FC の利点：戻り値の型チェック

ここまで React.FC の問題点を挙げてきましたが、一方で React.FC には戻り値の型を制約してくれるという利点があります（React 19 では ReactNode | Promise<ReactNode>、それ以前では ReactNode）。

// React.FC あり → コンパイルエラーで検知できる
const BadComponent: React.FC = () => {
  return new Date(); // ✕ 型エラー: 'Date' is not assignable to type 'ReactNode'
};

// 型注釈なし → エラーにならず、ランタイムでクラッシュする
const BadComponent = () => {
  return new Date(); // コンパイルは通るが、実行時に "Objects are not valid as a React child" エラー
};

React.FC を使わない場合、関数の戻り値に型制約がないため、Date やオブジェクト、void など React がレンダリングできない値を返してもコンパイル時に検出できません。これは特にコンポーネントが複雑になり、条件分岐で異なる値を返すようなケースでリスクが高まります。

この問題への対策は、次のセクションで紹介する「戻り値に : React.ReactNode を明示する」方法で解決できます。

現在の推奨される書き方

interface CardProps {
  title: string;
  subtitle: string;
  children?: React.ReactNode; // 必要な場合のみ明示する
}

const Card = ({ title, subtitle, children }: CardProps): React.ReactNode => {
  return (
    <div className="card">
      <h2>{title}</h2>
      <p>{subtitle}</p>
      {children}
    </div>
  );
};

この書き方のメリットは以下の通りです。

1. シンプル: 特別なインターフェースを介さず、素の TypeScript の関数として記述できる。
2. 明示的: Props の定義が関数の引数に直接現れるため、未使用の Props に気づきやすい。
3. 柔軟: ジェネリクスやデフォルト引数との相性が良い。
4. 戻り値の型安全性: : React.ReactNode を明示することで、React.FC と同等の戻り値チェックが得られる。

既存コードの移行

Gusto のように大規模なコードベースを修正する場合、手動での対応は現実的ではありません。以下の codemod を使うことで、一括変換が可能です。

codemod-replace-react-fc-typescript

npx jscodeshift \
  -t https://raw.githubusercontent.com/gndelia/codemod-replace-react-fc-typescript/main/dist/index.js \
  --extensions=tsx \
  src/

実行後は、displayName や defaultProps を利用している箇所に影響がないか確認し、Prettier 等でフォーマットを整えるのがスムーズです。

まとめ

比較項目	React.FC	通常の関数
余剰プロパティチェック	挙動が不安定になる場合がある	常に厳密
余剰プロパティチェック（訂正）	通常の関数と同様に機能する	厳密
children の扱い	暗黙的に含まれる（v17以前）	常に明示が必要
ジェネリクス	非対応	対応
default引数	型推論が不完全な場合がある	正常に動作
defaultProps（訂正）	required な Props を省略可能にできない（v18以前）。v19 では廃止	defaultProps が正しく推論される
関数型への代入（React 19）	(props: P) => ReactNode に代入不可	問題なし
戻り値の型チェック	自動で ReactNode に制約	明示的に : ReactNode を付ける必要あり

React.FC が致命的なバグを引き起こすわけではありません。Total TypeScript の記事でも TypeScript 5.1 以降は「React.FC is now officially 'fine'」と評価されています。しかし、Gusto が数千のコンポーネントを移行して「隠れていた未使用の Props」を見つけ出したという事実は、通常の関数コンポーネントの方がよりコードの見通しが良く、リファクタリングを促進しやすいということを示しています。

これから新しくコンポーネントを作成するのであれば、特別な理由がない限り、通常の関数として定義するのが良いのかなと思いました。ただし、React.FC を使わない場合は戻り値に : React.ReactNode を付けることを推奨します。これにより React.FC が提供していた戻り値の型チェックと同等の安全性を確保できます。

参考資料

• The Journey to a Safer Frontend - Gusto Engineering
• Since TypeScript 5.1, React.FC is now "fine" - Total TypeScript
• Function Components - React TypeScript Cheatsheet
• React 19の型定義では「FC」と「ReactNodeを返す関数」が違う