Reactコンポーネントを解剖する：データの流れと構造の理解
セッションの第2パートでは、「Reactコンポーネントの一般的な構造」をテーマに、フロントエンドにおけるデータの流れをステップごとに解説した。
「重要になるのは、データの流れだ」とパンダ氏は強調する。例として示されたのは、記事データをAPIから取得し表示する「Articleコンポーネント」だ。ここでは、以下の4ステップに沿って構造を理解していく。
1．データの取得（Fetch）
Reactでは、useEffect内でfetchを使ってAPIからデータを取得し、その結果をuseStateで状態として保持する。データの取得と状態管理は一体であり、「セットで考えるのが大切」とパンダ氏は述べる。
2．状態と描画の関係
取得したデータがstateにセットされると、コンポーネントが再描画される。初期状態では「Loading…」などを表示し、データ取得後に実際の内容（記事タイトルや本文など）を描画する。この「状態が変われば画面が変わる」という基本原則は、React以外のフレームワークでも共通して重要な考え方だ。
なお、ここで紹介している手法はReactの古い記法であり、現在はよりモダンなアプローチが存在するが、あえて今回は構造がわかりやすい方法を用いている点には注意したい。
3．ロジックの分担
コンポーネント内部のロジックは大きく3つに分かれる。1つ目は前述の状態管理。2つ目がイベントハンドリングで、ユーザーの操作（例：クリック）に反応して状態を変更する関数群だ。3つ目がプレゼンテーションロジックで、たとえば「2週間前」「1か月前」といった相対的な日付の表現など、データをユーザーにとってわかりやすく表示するための変換処理を担う。
4．表示（JSX）
これらを統合するのが、JavaScript内でHTMLライクな構文を書けるJSXだ。JSXは見た目にはHTMLに近いが、あくまでJavaScriptの構文であり、最終的にはReact.createElementなどの関数呼び出しに変換され、仮想DOMを通して画面にレンダリングされる。
「JSXはHTMLそのものではなく、“シンタックスシュガー”として構文を簡潔に記述できるもの」とパンダ氏は解説する。また、JSXはJavaScriptの一部であるため、TypeScriptとの相性も良く、型安全な開発を支える要素にもなっている。
バックエンドの視点で読み解くReact
第3パートでは「Reactコンポーネントの構造を、バックエンドエンジニアの視点でどう理解するか」がテーマとなった。パンダ氏は、先に紹介した4つのステップ「Fetch」「State」「Logic」「JSX」を軸に、それぞれの役割と考え方を丁寧に紐解いていった
1．データの取得（Fetch）
まずReactでは、useEffectとfetchを用いてAPIから非同期にデータを取得する。この取得処理は、コンポーネントの初回レンダリング後に実行される仕組みだ。
「以前はクラスコンポーネントで componentDidMount を使っていましたが、今では useEffect に置き換わっています」とパンダ氏は補足する。なお、このデータ取得のロジックはReact v19以降、外部に切り出される設計が主流になってきており、「APIコールは“準構成要素”として捉えたほうがよい」として、今回は補助的な扱いにとどめている。
2．状態の保持と描画（State）
取得したデータは useState を使って状態として保持される。ここで重要になるのが「状態と描画の関係」だ。
Reactでは、状態が更新されるたびにコンポーネントが再描画される。これは「ステートパターン」と呼ばれる設計手法に近い概念であり、「状態が変われば振る舞いが変わる」構造になっている。
この考えを説明するために、パンダ氏は「マリオの進化」をたとえに用いた。最初は小さいマリオが、スーパーキノコを取って大きくなり、さらにファイアフラワーを取るとファイアマリオに進化する。そしてファイアマリオになることで新しい振る舞い（＝攻撃）が可能になる。つまり、キャラクターの状態によって可能なアクションが変わる──この仕組みがステートパターンであり、Reactでも状態に応じて表示が変化するのと同じである。
この動作原理は、Reactの中核をなす次の数式にも表れている。
UI = f(props, state)
「この式はReactの本質を表しています」とパンダ氏。コンポーネント（f）は、props（外部から渡ってくるデータ）とstate（内部で保持する状態）という入力に応じて、常に同じUIを返す──副作用のない関数型的な発想に基づいた宣言的UIだと述べる。
3．ロジックの分担（Logic）
ここでパンダ氏は再度、「Reactのコンポーネント構造とオブジェクト指向プログラミング（OOP）のメソッド構造には、共通点がある」との観点を提示する。
例として挙げられたのが、『オブジェクト指向設計スタイルガイド』に登場するメソッドの書き方のテンプレートだ。そこでは、事前条件のチェック、失敗時の処理、ハッピーパス、本来の処理、事後条件のチェックという構造的な型が提示されている。
一方でReactのコンポーネントもまた、「状態管理」「イベントハンドリング」「表示ロジック」「構文（JSX）」といった関心ごとに構造化されている。こうした整理の仕方は、OOPにおける"関心の分離"や"単一責任の原則"などの設計思想に通じる。
4．表示構文としてのJSX
JSXについてはセッション第2パートでも取り上げられたが、第3パートでは「構文としての見た目」ではなく、「構造的な意味」に重きを置いた解説がなされた。
パンダ氏は、「JSXは見た目こそHTMLに似ているが、実際にはJavaScriptの関数呼び出しとして構成される」と解説する。たとえば <Loading /> という記述は、最終的には React.createElement("div", null, "Loading...") のような関数形式に変換される。
この構造的な変換は、HTMLのツリー構造をそのままJavaScriptのネストされた関数として捉えるものであり、「マークアップではなく、構造の定義としてJSXを理解すると把握しやすくなる」と氏は話す。
こうした視点をもつことで、JSXの役割が単なる見た目の記述にとどまらず、「構造を記述するための技術」へと拡張される。バックエンド出身のエンジニアにとっても、関数型やオブジェクト指向と親和性のある考え方として、理解の糸口になるだろう。
こうして、Reactコンポーネントの構造を「状態管理」「イベントハンドリング」「プレゼンテーションロジック」「JSX」という4つの視点で分解しながら見てきた。これらはいずれもフロントエンドにおけるUI構築の基本的な要素であるが、「オブジェクト指向プログラミングの知識が、理解に役立ったのではないか」とパンダ氏は改めて問いかける。
「結局のところ、新しいことを学ぶときには、“うまいたとえ”や“とっかかり”があると理解しやすい」とパンダ氏。フロントエンドの学習を“ゼロからの挑戦”にせず、“積み上げてきた知識の応用”として位置づける本セッションは、新たな技術への一歩を後押しするものとなったのではないだろうか。
【関連記事】 プログラミングをするパンダ氏 執筆記事は以下よりチェック！
