ブログ記事
Reactのコードが乱雑になる本当の理由：『Reactハンズオンラーニング 第2版』で学ぶ関数型思想とコンポーネント設計
コンポーネントに機能を追加するたびに、コードが読みにくくなっていく——その原因は「なぜそう書くのか」が曖昧なまま実装を積んでいることにある。
flowchart LR
subgraph NG["❌ 命令型（状態が散在）"]
I1["DOM要素を取得\n→ 直接書き換え\n→ 複数の状態が絡まる"]
end
subgraph OK["✅ 宣言型（React）"]
S["state 定義"] --> R["state に応じた\nUIを宣言"]
R -->|"stateが変わると\n自動で再レンダリング"| S
end
style NG fill:#fce8e8,stroke:#e53935
style OK fill:#e8f8e8,stroke:#4caf50
Alex Banks と Eve Porcello による『Reactハンズオンラーニング 第2版』（オライリー・ジャパン、2021年）は、React の API 仕様を表面的に追うのではなく、その背後にある設計思想から紐解く。「なぜ React は宣言的な書き方を求めるのか」「なぜ状態の不変性を守らないとバグが起きるのか」という根拠を、関数型プログラミングの原則と結びつけて説明している。
1. なぜ「関数型プログラミング」から始めるのか
本書の序盤は React の説明ではなく、JavaScript における「命令型」と「宣言型」の違い、そして純粋関数・イミュータビリティ・高階関数という関数型の基礎概念の整理に充てられている。
DOM を直接操作する命令型のコードは、処理ステップを逐一記述するため、状態が複数箇所から書き換えられると追跡が難しくなる。一方、状態を定義してそれに応じた UI を宣言的に記述するアプローチは、アプリの規模が大きくなっても見通しを保ちやすい。React がこの「宣言的」なパラダイムを採用しているのは設計上の必然であり、本書はその理由を丁寧に言語化している。
この基礎を先に押さえることで、フックの設計意図やコンポーネントの責務分割が「なんとなくそうなっている」ではなく「こういう理由でこう書く」という理解に変わる。他のフレームワークから来た開発者や、チュートリアルを終えたばかりの読者にとって、この構成は得るものが大きい。
2. カスタムフックで「UIとロジック」を分離する
本書の後半では、シンプルなコンポーネントから始めて段階的にリファクタリングを重ねる流れが繰り返される。useState や useRef の基本的な使い方から出発し、重複するロジックをカスタムフックに切り出し、Context API で複数コンポーネントをまたいだ状態注入へと進んでいく。
コンポーネントが肥大化する原因の多くは、UI の描画コードと状態管理、外部通信のロジックが1ファイルに混在していることにある。カスタムフックを使ってロジックを分離する手順を実際のコードで追うことで、「関心の分離」という概念が抽象論ではなく具体的な作業として把握できる。
また、useMemo や useCallback といったメモ化フックについても、使いどころと使わないほうがよい局面の両方が示されている。過度な最適化は可読性を損なうという視点は、「とりあえず全部メモ化しておく」という誤った最適化を防ぐ上で実用的だ。
3. 現代の環境で使う際に注意すること
本書のサンプルは Create React App（CRA）を基準に書かれている。CRA は現在では非推奨・開発停止状態であるため、最新の Node.js 環境でそのまま動かそうとすると問題が生じやすい。
具体的には、OpenSSL の仕様変更に起因するビルドエラー（ERR_OSSL_EVP_UNSUPPORTED）や、Windows 標準環境での rm コマンドの非認識といった障壁がある。これらは NODE_OPTIONS=--openssl-legacy-provider の設定や WSL 環境の利用で回避できるが、初学者にはトラブルシューティングの負担が大きい。
現在から本書を使うなら、プロジェクトのセットアップは Vite（React + TypeScript + SWC）に切り替えて進めるほうが現実的だ。書籍の解説内容自体——宣言的 UI の考え方、フックの設計、Context API の使い方——は今も通用するため、環境の違いを意識しながら読み進めることで本書の価値は十分引き出せる。
4. この本が効く場面
「チュートリアルどおりには作れるのに、自分のアプリを書き始めるとコンポーネントがどんどん膨らみ、分割や共通化の判断が下せない」——本書が最も効くのはこの状況だ。状態をどこに置くか、ロジックをいつカスタムフックへ切り出すかを、完成度の高いコードを段階的にリファクタリングしていく実演で追体験できるため、読後は分割や共通化の判断を理由付きで下せるようになる。
もう一つは、Vue や Angular から React に移り、JSX の記法やフックの発想への違和感が拭えないまま書いている状況。本書はリアル DOM と仮想 DOM の違いや、純粋関数・不変性が重視される理由の説明から入るため、「そういう決まりだから」と飲み込むのではなく、理屈で React の流儀に馴染み直せる。
5. 「ハンズオン」という書名から生まれる誤解
書名から「ゼロから一つのアプリを手順どおりに組み上げていくワークブック」を想像すると、期待とずれる。実際の本書は、著者が用意したレシピアプリなどの完成度の高いコードを土台に、各要素の解説とリファクタリングの手法をコードリーディング的にたどる構成で、自分の手でアプリが育っていく達成感を求めた読者からは期待と異なったという不満も出ている。
裏を返せば、本書は「動くものを作る」より「コードが洗練されていく過程を見る」ための本だ。単一のコンポーネントから始めて、ステートの一元管理、Context を使った複数コンポーネントへのステート伝達、カスタムフックへの切り出しと段階を踏んで作り替えていく実演は、洗練のプロセスを追体験する教材として評価されている。作り上げる本ではなく、書き方を変える本として手に取るのが正しい距離感だ。
6. こんな人に向いている
向いている人：
- 超入門書やチュートリアルを終え、文法どおりの実装はできるが、UI 描画と状態管理・外部通信のロジックが混ざった保守しにくいコードになりがちな人
- Vue や Angular での開発経験があり、JSX の記法やフックの概念に違和感を残したまま React を書いている人
- React の API の使い方は覚えたが、「なぜそう書くのか」の根拠から理解し直したい人
向いていない人：
- JavaScript の文法をこれから学ぶ人（本書は ES6 文法の理解を前提に、序盤の2章で JavaScript の新仕様と関数型の基礎を整理する構成で、言語そのものの入門書ではないため）
- 手を動かしてゼロから一つのアプリを完成させる体験型チュートリアルを求める人（前節のとおり、完成済みコードの解説とリファクタリングの実演が中心のため）
7. 読んだ後の次の一歩
本書で React 単体の開発に軸ができたら、進む先は関心で分かれる。ルーティングやデータ取得まで統合された環境で実際のプロダクトを組み立てたいなら、App Router とサーバーコンポーネントを前提にした『実践Next.js』が次の段階になる。「なぜこの書き方だと再レンダリングが増えるのか」といった内部動作へ関心が向いたなら、Fiber アーキテクチャまで踏み込む『Fluent React』が本書で得た理解を一段深くする。
書籍に進む前の最初の一歩として、いま手元にあるコンポーネントから UI と関係のないロジックを一つだけカスタムフックに切り出したい。本書のリファクタリングの流れを自分のコードで再現すると、「関心の分離」が読んだ知識から使える技術に変わる。
筆者の体験から
転職して最初に配属された案件ではjQueryでDOMを直接操作するコードばかり書いており、React案件へのアサインを機に入門書を一通りこなしたが、stateを直接書き換えて画面が更新されなくなる失敗を繰り返し、「宣言的に書く」という言葉が実感を伴わなかった。本書序盤の純粋関数と不変性の説明を読んで、「宣言的に書く」の意味がようやく像を結び、癖が抜けた。カスタムフックへの切り出しは、コンポーネントが肥大化したときの最初の一手として今も使っている。書名の「ハンズオン」から手順どおりアプリを組み上げる本を想像していたため、完成済みコードを読み解く構成だと分かった当初は肩透かしだった。
案件で最初に触ったのは、データ取得と描画を一つのコンポーネントに詰め込んだコードで、先輩に「テストが書きにくい」と指摘された。本の後半で読んだカスタムフックへの切り出しを思い出し、データ取得とローディング状態を独自フックに移すと、同じフックを別画面でも使い回せ、テストもフックとコンポーネントで分けて書けた。「関心の分離」を初めて手を動かして理解した瞬間だった。
DevBookPathのマップで確認する
この本の学習パス上の位置づけ・前後の読書順は、DevBookPath のグラフで辿れます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有