【実務・中級編】 Default Propsとデフォルト引数の使い分け – React実践ガイド

やあ、調子はどうだい？
日々、コンポーネントを量産してチケットを消化しまくっていることと思う。

さて、今回はReactの「Propsによるデータの受け渡し」の核心、それも中級へのステップアップで必ず引っかかる「Default Propsとデフォルト引数の使い分け」について話をしよう。

ここだけの話、このテーマ、公式ドキュメントの記述が変遷してきた歴史的経緯もあって、実務の現場でも「どっちを書くのが正解なんだっけ？」と手が止まるエンジニアが後を絶たない。レガシーなコードベースを開けば `defaultProps` の山、最新のトレンドを追えば「いや、ES6のデフォルト引数一択でしょ」と言われる。

シニアの視点から言わせてもらうと、この論争にはもう明確な決着がついている。
今回は、なぜその結論に至ったのか、JavaScriptのランタイムやReactの裏側の処理まで解き明かしながら、明日から君のコードを美しく、かつバグ知らずにするためのベストプラクティスを授けよう。

—

1. 歴史的背景：なぜ私たちは `defaultProps` から離れるのか

まずは敵を知ることから始めよう。
Reactのクラスコンポーネント全盛期、そして関数コンポーネントの初期において、Propsの初期値を定義するための公式な作法は `defaultProps` だった。

// 昔懐かしいスタイル
function UserCard(props) {
return

{props.name}

;
}

UserCard.defaultProps = {
name: ‘名無しのエンジニア’,
};

これ、一見すると何の問題もないように見える。しかし、Reactのバージョンアップ、そしてTypeScriptの普及に伴い、この `defaultProps` は「静的解析の不都合な真実」を抱えていることが露呈してきた。

1-1. TypeScriptとの相性が最悪という現実

現代の開発において、TypeScriptはもはや空気のような存在だ。型安全のないReactなんて、ブレーキの壊れたスポーツカーみたいなものだからね。
ここで `defaultProps` を使おうとすると、型定義とデフォルト値の二重管理が発生したり、ジェネリクスを使った複雑なコンポーネントにおいて、推論が盛大にバグるという悪夢を何度も見てきた。

1-2. Reactの裏側で何が起きているか（ブラウザの処理）

Reactのレンダリングエンジンは、JSXを解釈し、コンポーネントを呼び出す際、親から渡されたPropsオブジェクトをそのまま、あるいは合成して子コンポーネントに渡す。
`defaultProps` を使っている場合、Reactの内部で「Propsオブジェクトにそのプロパティが存在しない（または `undefined` である）場合、`defaultProps` から値を探して補う」というオーバーヘッドが発生する。

これに対して、現代の主流である「JavaScriptのデフォルト引数（Default Parameters）」はどうだろうか？

—

2. 現代のスタンダード：JavaScriptデフォルト引数の圧倒的優位性

では、現在のベストプラクティスである「分割代入におけるデフォルト引数」を使ったコードを見てみよう。実務でそのまま使えるクリーンな例だ。

現場で使える実用コード例

import React from ‘react’;

// 1. Propsの型定義（オプショナルなプロパティには ‘?’ をつける）
interface ButtonProps {
label?: string;
variant?: ‘primary’ | ‘secondary’ | ‘danger’;
isLoading?: boolean;
onClick: () => void;
}

export const AppButton: React.FC = ({
// 2. 分割代入の段階でデフォルト値を設定する
label = ‘送信する’,
variant = ‘primary’,
isLoading = false,
onClick,
}) => {
// スタイルをバリエーションに応じて切り替えるロジック（簡略化）
const baseStyles = ‘px-4 py-2 rounded font-bold transition-all’;
const variantStyles = {
primary: ‘bg-blue-600 text-white hover:bg-blue-700’,
secondary: ‘bg-gray-200 text-gray-800 hover:bg-gray-300’,
danger: ‘bg-red-600 text-white hover:bg-red-700’,
}[variant];

return (

);
};

なぜこれが優れているのか？（論理的解説）

1. JavaScriptのネイティブ機能であること
Reactというフレームワークの仕様に依存せず、ECMAScriptの標準仕様（ES2015+）に乗っかっている。そのため、ブラウザのJavaScriptエンジン（V8など）が最適化しやすい。
2. TypeScriptとの完璧なシナジー
`interface` 側で `label?: string` とオプショナルにしておき、引数側で `label = ‘送信する’` と書くだけで、コンポーネント内のコードにおける `label` の型は自動的に `string` として確定する（`undefined` が消え去る）。これがどれだけ開発体験を爆上げするか、君なら分かるはずだ。
3. コードの局所化（Locality of Behavior）
コンポーネントの定義を見た瞬間に、引数のリストの上でデフォルト値が完結している。わざわざファイルの末尾や別の場所に `Component.defaultProps = { … }` を探しに行く必要はもうないんだ。

—

3. 「ちょっと待て！」：実務でハマる落とし穴と例外

さて、ここまで「デフォルト引数最高！」という話をしたが、シニアとして実務の泥臭い注意点も共有しておかなければならない。

罠：`undefined` 以外の「偽値（Falsy）」の挙動

JavaScriptのデフォルト引数は、渡された値が 厳密に `undefined` の場合 にのみ発動する。
これが何を意味するか分かるかい？親から明示的に `null` や `false`、空文字 `””` が渡された場合、デフォルト値は上書きされない。

// 親コンポーネントから null が渡された場合

// → デフォルトの ‘送信する’ にはならず、null がそのまま処理されようとしてバグる原因になる！

もし、親コンポーネントの設計上、`null` や `undefined` の両方を「値がない」とみなしてデフォルト値にフォールバックさせたい場合は、論理演算子や三項演算子を組み合わせる防衛的プログラミングが必要になる。

export const SafeButton = ({ label }: ButtonProps) => {
// null または undefined の場合にデフォルト値を適用する堅牢な書き方
const resolvedLabel = label ?? ‘送信する’;

return ;
};

※ `??`（Nullish coalescing operator）は、`null` と `undefined` のみを検知してくれる現代JSの強い味方だ。積極的に使っていこう。

—

4. チームへの展開と今後の公式動向

実は、Reactのコアチームもこの流れを完全に認めている。
公式のRFCや議論でも、関数コンポーネントにおける `defaultProps` は「将来的に非推奨（Deprecated）にする方向で検討中」とされている。関数コンポーネントに対する `defaultProps` のサポートは、徐々に縮小していくトレンドにあるんだ。

だからこそ、チームのコードベースをレビューする時は、以下のガイドラインを共有してほしい。

新規作成するコンポーネント：すべて「分割代入のデフォルト引数」で実装する。
型定義：Propsのインターフェース側は `?` を使ってオプショナルにし、実装側で初期値を担保する。
既存の `defaultProps`：リファクタリングのタイミングで、少しずつデフォルト引数に置き換えていく。

—

まとめ

技術の変遷は早い。昨日までのベストプラクティスが、今日のアンチパターンになることはザラにある。
しかし、「なぜその仕様になり、ブラウザやランタイムはどう処理しているのか」という根っこを理解していれば、トレンドに振り回されることなく、自信を持って美しいコードを書くことができるはずだ。

さあ、今日のタスクに戻るとしよう。君が書く次のコンポーネントのデフォルト引数が、美しく型安全に実装されるのを期待しているよ！