【テクニカル・上級編】 JSXでの条件付きレンダリング – React実践ガイド

Reactを書くとき、私たちは無意識のうちにJSXで条件分岐を書いています。「`&&`で出し分ければいい」「三項演算子ならスッキリする」。確かにその通りですが、大規模アプリケーションの複雑な状態遷移の中で、その「気軽な分岐」がレンダリングの負債となって蓄積していく様子を、君は見たことがありますか？

今日は、ただ「動く」コードから、「枯れた」堅牢なアーキテクチャへと昇華させるための、JSXの条件付きレンダリングに潜む深淵を紐解いていきましょう。

—

もっとも一般的な `condition && ` というパターン。これには、JavaScriptの仕様に起因する重大な罠が潜んでいます。

// ありがちなアンチパターン
// countが0の場合、ReactはDOMに「0」というテキストノードをレンダリングしてしまう
{items.length && }

もし `items.length` が `0` だった場合、Reactは `0` を有効なレンダリング結果としてDOMに挿入します。これはUIに不要な「0」という文字を表示させるだけでなく、ReactのReconciliation（再調整）プロセスに無駄なノード判定コストを強いることになります。

解決策：明示的なブーリアン変換
二重否定 `!!` や `Boolean()` を使うのは、もはや現場の常識です。

// 堅牢な記述
{!!items.length && }

—

条件付きレンダリングをどこで行うか。これはパフォーマンスに直結する設計の根幹です。安易にJSXの中で条件分岐を行い、コンポーネントをその場で定義したり、頻繁にマウント・アンマウントを繰り返すと、Reactのパフォーマンスは崩壊します。

特に注意すべきは、親のレンダリングによって子コンポーネントが常に再生成される構造です。

// 避けるべき設計：条件分岐のたびにコンポーネントが再作成される可能性がある
const Parent = ({ data }) => {
return (

{/ 複雑な条件式がここにあると、可読性もパフォーマンスも低下する /}
{data.isValid ? : }

);
};

アーキテクチャの知見：
条件分岐をコンポーネントの「外」に追い出す、あるいは条件の結果をカスタムフックや、専用の「ゲートウェイ・コンポーネント」にカプセル化してください。レンダリングパイプラインを簡素化し、`React.memo` の効果を最大化するためです。

—

データ取得中のローディング状態と、データが存在する状態を `&&` で繋ぐコードをよく見かけますが、非同期の競合（Race Condition）を考慮していますか？

// 危険なレンダリング
{isLoading && }
{!isLoading && data && }

ここで `isLoading` が false になった瞬間に `data` がまだ存在しない、あるいは古い状態である可能性を排除できません。複雑な状態遷移をJSXの `&&` だけで制御しようとすると、状態の組み合わせ（組み合わせ爆発）により、UIのちらつきや予期せぬエラーを招きます。

スペシャリストの解決策：ステートマシンによる宣言的制御
複雑な分岐はJSXから排除し、`status` というステートマシン（`idle`, `loading`, `success`, `error`）を導入しましょう。

—

最後に、メモリ効率とレンダリング負荷について。
条件付きレンダリングによってコンポーネントが削除されるとき、Reactは内部のStateやRefをすべて破棄します。これはメモリ管理としては正しい挙動ですが、ユーザー体験としてはコストが高い場合があります。

もし、条件が切り替わるたびに重いコンポーネントを再マウントさせたくない場合は、CSSの `display: none` による制御を検討すべきです。

—

ReactのJSXにおける条件付きレンダリングは、単なる条件分岐ではありません。それはコンポーネントのライフサイクルを制御する「宣言」です。

「とりあえず動く」コードを書くのはジュニアでもできますが、メモリの解放、レンダリングの競合、そして後から読む誰かの脳内負荷まで考慮してコードを書くのがプロフェッショナルです。

複雑な条件分岐はUIの「複雑度」の現れです。もしJSXが `&&` や `三項演算子` で埋め尽くされているなら、それは設計を見直すサインかもしれません。より宣言的で、より予測可能なコードを目指しましょう。それが、君のアプリケーションを次のステージへと押し上げる唯一の道です。