やあ。Reactを触り始めてしばらく経つと、コンポーネント間でPropsをどう受け渡すかという「作法」に迷うことはなくなるだろう。だが、中級者として一歩先へ進むなら、「ただ動くコード」ではなく「意図が明確で、拡張性に優れたコード」を書く必要がある。
今日は、ReactのProps受け渡しにおける「現場のリアルな勘所」を共有しよう。
—
1. JSXにおけるPropsの基本:静的と動的の使い分け
JSXで属性を書くとき、初心者がやりがちなのが「なんでもかんでも波括弧 `{}` で囲む」ことだ。だが、Reactの仕様を理解していれば、もう少しエレガントに書ける。
文字列リテラルは「そのまま」書く
静的な文字列を渡すときは、波括弧は不要だ。
// 悪い例:波括弧の無駄遣い
// 良い例:文字列ならそのまま書く(HTMLの属性と同じ感覚で)
ブラウザのレンダリングエンジンから見れば、結果は同じPropsオブジェクトになる。だが、コードの可読性という観点では「波括弧がある=そこにJavaScriptの評価(式)が存在する」というシグナルとして機能させるべきだ。余計な記号は認知負荷を高めるだけだからね。
式(Expression)の真価
逆に、変数や数値、真偽値、関数を渡すときは波括弧が必須だ。ここで重要なのは、「渡すのは値だけではない」ということだ。
// 現場でよく見る「Propsの注入」
/>
—
2. スプレッド演算子(`{…props}`)の光と影
React中級者が必ず通る道が、スプレッド演算子によるPropsの一括展開だ。これは非常に強力だが、「便利だから」という理由だけで乱用してはいけない。
なぜスプレッド演算子は危険なのか?
スプレッド演算子を使うと、コンポーネントが「どのPropsを必要としているか」が隠蔽される。TypeScriptを使っていれば型エラーで弾けるが、それでも「Propsのバケツリレー(Prop Drilling)」を助長する温床になりやすい。
// 悪い例:受け取ったpropsを全部横流しする
const Container = (props) =>
現場で推奨する「Propsのフィルタリング」
特定のコンポーネントに余計な属性を渡さないことは、パフォーマンスと保守性の両面で重要だ。
interface ButtonProps {
label: string;
onClick: () => void;
// 意図的に受け取らない属性は除外する
[key: string]: any;
}
const SmartButton = ({ label, onClick, …rest }: ButtonProps) => {
// restにはlabelとonClick以外の属性が格納される
// これをDOMに展開する際は注意が必要だ
return (
);
};
—
3. 型定義とコンポーネントの「設計思想」
TypeScriptでPropsを定義する際、`interface`を使うか`type`を使うかは宗教論争に近いが、「コンポーネントの責務をどう切り出すか」を優先してほしい。
現場で使える「Propsの合成」パターン
複数のコンポーネントで共通するPropsを、いちいち再定義するのは時間の無駄だ。
type BaseProps = {
className?: string;
children: React.ReactNode;
};
// 既存の型を拡張して、独自のPropsを追加する
interface CardProps extends BaseProps {
title: string;
elevation?: ‘low’ | ‘high’;
}
export const Card = ({ title, children, elevation = ‘low’ }: CardProps) => {
return (
{title}
{children}
);
};
—
4. 裏側で何が起きているのか?(Reactの深層)
ブラウザがDOMを生成する直前、Reactは君が書いたJSXを `React.createElement(type, props, …children)` という関数呼び出しに変換している。
君が書いた `` は、実際には以下のように解釈される。
React.createElement(Button, { label: “保存” }, null);
この「Propsオブジェクト」がコンポーネント関数に渡され、Reactはその結果(仮想DOMツリー)を比較して、必要な箇所だけをブラウザのDOMに反映する。Propsの受け渡しは、単なる関数の引数渡しに過ぎない。 だからこそ、複雑なロジックをPropsの中に直接書こうとせず、できる限り「値の受け渡し」に徹するべきなんだ。
—
最後に:シニアからのアドバイス
君がもし「Propsの受け渡しが長すぎてコードが汚い」と感じたら、それは技術力の問題ではなく、コンポーネントの責務が大きすぎるという設計上のサインだ。
- Propsが多すぎるなら? → コンポーネントを分割するか、Contextや状態管理ライブラリを検討する。
- Propsの渡し方が複雑なら? → それはコンポーネントの「境界」が曖昧だということだ。
Reactのコードは、いかに「宣言的に」書くかが勝負だ。Propsはコンポーネントへの「設定値」であると割り切り、シンプルで予測可能な設計を心がけてみてほしい。
何かあればいつでも聞いてくれ。現場の泥臭い悩みほど、エンジニアを成長させるものはないからね。

コメント