やあ。フロントエンドの最前線で日々コンポーネントと格闘している君たちへ。
Reactを触り始めてしばらく経つと、「条件付きレンダリング」なんて当たり前すぎて呼吸するように書いているはずだ。しかし、ふとコードレビューをしていると、`&&`演算子の落とし穴にハマっていたり、三項演算子のネストで地獄絵図のような可読性の低いコードに出くわすことが少なくない。
今日は、Reactの裏側で何が起きているのかという「解像度」を高めつつ、実務で明日から使える「美しい条件分岐」の作法について話そう。
—
1. なぜReactは「if文」をテンプレートに直接書けないのか
まず大前提として、JSXは単なる「見た目のための糖衣構文」だ。ビルド時に`React.createElement`（あるいは最近の新しいJSX変換）に置き換わる。
// これが
// こう変換される（イメージ）
React.createElement(‘div’, { className: ‘box’ }, ‘Hello’);
ここで重要なのは、JSXはJavaScriptの式（Expression）であるということ。`if`文や`for`文は「文（Statement）」であって「式」ではない。だから、JSXの波括弧 `{ }` の中には`if`を直接ぶち込めないんだ。この制約があるからこそ、我々は「式」として評価される演算子を駆使する必要がある。
—
2. 実務で遭遇する「&&演算子」の罠
多くのエンジニアがやらかすのがこれだ。
// 危険な例: countが0の時、画面に「0」が表示されてしまう
{items.length &&
JavaScriptの `&&` 演算子は、左辺がfalsyならその値を返し、truthyなら右辺を返す。`0`はfalsyだが、Reactのレンダリングにおいて`0`は「表示すべき値」として扱われるため、画面上に意図せず「0」という数字がポツンと浮き上がることになる。
解決策：明示的にBooleanへ変換する
一番確実なのは、二重否定 `!!` を使うか、比較演算子で明確にすることだ。
// 現場のベストプラクティス：確実にBooleanにしてから渡す
{!!items.length &&
// もしくは、さらに読みやすく比較する
{items.length > 0 &&
—
3. 三項演算子の「ネスト地獄」から脱出する
三項演算子（`condition ? a : b`）は便利だが、三段重ねになるとコードの可読性は急降下する。そんな時は、無理にJSXの中に押し込まず、コンポーネント外（または関数の冒頭）でレンダリング用の変数を定義するのが正解だ。
const StatusMessage = ({ status }) => {
// レンダリング前のロジックとして切り出す
const getMessage = () => {
if (status === ‘loading’) return
if (status === ‘error’) return
return
};
return (
);
};
「JSXを簡潔に保つ」ことこそが、後からコードを読む未来の自分やチームメンバーへの最大のギフトだ。
—
4. 実戦で使うべき「ガード節」パターン
関数コンポーネントの冒頭で早期リターン（Early Return）を使うのは、もはや常識だろう。これを使うことで、UIのメインロジックを読みやすくできる。
const UserProfile = ({ user }) => {
// 読み込み中やデータがない場合のガード節
if (!user) return
// 権限がない場合など
if (!user.isActive) return
// 本丸のレンダリング
return (
{user.name}
{/ … /}
);
};
この手法の素晴らしい点は、「正常系」のコードがインデントに深く埋もれないことだ。UIの分岐が複雑な時ほど、このスタイルを採用してほしい。
—
最後に：コードは「誰が読むか」を意識しろ
Reactのレンダリングは、ブラウザのメインスレッドを占有する。無駄に複雑な条件分岐は、コードの可読性を下げるだけでなく、意図しない再レンダリングの温床にもなり得る。
1. `&&`を使うなら`0`のケースを常に意識せよ。
2. 三項演算子が2階層以上になるなら、関数や変数に分離せよ。
3. 迷ったら早期リターンを使い、コンポーネントをフラットに保て。
この3つを意識するだけで、君の書くコードは「動くもの」から「メンテナンス可能な資産」へと進化するはずだ。
現場からは以上だ。何か詰まったら、またいつでも聞いてくれ。良いコードを書いていこう。
コメント