🌰
Reactで学ぶ技術習得ハンズオン - OSS探索法

2024/11/03に公開
2件
 初めにこの記事では、

「初見技術のキャッチアップの仕方・過程の一つの道標を残す」

ことに焦点を絞っています。その一例として、

Reactをゼロからキャッチアップする工程を記録しています。

　経緯として、周囲から勉強法について聞かれることがあったこと、また、過去に学習の仕方やキャッチアップのコツがわからないという経験をしており、この記事だけでは全てを伝えることは難しいのとまだ勉強中の身ではありますが、それでも少しでも雰囲気が伝わり、この記事を見た誰かの後押しになればいいなと思い作成しました。

なお、技術記事の作成は今回が初めてのため、修正点等あれば教えていただけると嬉しいです。

 この記事から学べること✅ 公式ドキュメント・技術記事から情報をキャッチアップしてまとめる流れが掴める

✅ 実際にキャッチアップを行う際に、どのような項目を大切にしているかが把握できる

✅ 実際に公式ドキュメントだけでは理解できない時にどのような手順でOSSのコードベースを見ていけばいいか詳細かつ段階的にわかる

✅ 初期位置からReactを1日でキャッチアップする流れがわかる、どこまでできそうか一例で把握できる

✅ React内部の要旨や開発時プラクティスの一例として何を考えているか知ることができる

 NOTEdocs:ドキュメントのこと
使用技術(エディタ): VSCode
フック:hooks

 目的の確認ReactのカスタムフックをReact自体をほぼ0からキャッチアップしながら開発に挑戦

 今回、実際何をしたか目的のためにdocsでキャッチアップを試みたが、技術記事などをみる中で自分の理解が本当に問題ないか、という疑問を持ったため、内部仕様を知るためにOSS内部を読み進めた

 所要時間docs・技術記事 3.0h
OSSコード内容分析 4.0h
技術記事作成 2.0h
計 9.0h

 初期位置の確認Reactは何となく把握しているが、公式docsをきちんと読んだ経験はなく、その時その時で何となく書いてた状態

 最初にしたことReactの公式docsを読む(スタート何とかみたいなところとクライアントAPI部分) - 2時間程
確認したこと
JSXとは何か
use系で状態管理をするのにアーキテクチャ的にどうなのか
責任分離としての公式のお薦めするプラクティスはどうなっているのか
Next.jsなどのFWがReactの標準で提供するAPIに加えてどのような内部的な処理を挟んで開発者のUXに貢献しているのか

途中でしたこと
わからない部分の詳細リンクをざっと見て感覚を掴む
コードベースで一部わかりにくいなと思ったところはGPTに聞いたり、わからない単語はGoogle検索

気づいたこと
Next.jsのApp Routerすごい
Reactを利用したUIレンダリング(CSR,SSR)におけるレンダリングのタイミングの調整を"use client","use server"+ファイル切り分けなどでブロックのスコープを切り分けて宣言するだけでdom操作を調整(+最適化？)してくれている
クライアントAPIを利用して開発するコスト対効果は平易な開発状況ではあまり無さそうな印象、開発+管理コスト増加によるデメリットが非常に大きく、そこを自動で管理してくれるNextのApp Routerや他FWを利用するのが良さそう



 意識しておいた方が良さそうなこと
 業務的な開発Tips事実ベースで開発+設計する
事実をどこから取得するか -> 公式docs、実際に動作しているコードベース(Githubなど)
業務で一回ミスした経験 -> GPTや技術記事などの根拠がないAPI情報などは参照せず、きちんと事実ベースで、サードパーティツールの公式docsを見にいくこと

視野が狭くならないように他の人の知見を学び、自身でも実践を続け、自身の設計+開発上のプラクティスを更新し続ける
汎用的なプラクティスを手札として構築するにはどうすればいいか -> 実はプログラミングというかソフトウェアレイヤーにおいて共通している概念モデルがあるのでそれを経験を積むうちに把握することで諸々の解像度を上げ、作業効率や学習速度を大幅に改善することができる
学習を継続すること - 技術記事、テックリファレンス、他のエンジニアから学ぶ・意見を聞く、技術書、実際に手を動かして演習 など - で基礎的な原則を十分に身につける


 キャッチアッププロセス以下のステップに従ってキャッチアップを行いました。
docs読み込み
技術記事参照
OSSコード調査

 docs読み込み・技術記事参照https://ja.react.dev/reference/react/useCallback#optimizing-a-custom-hook

を見て内容把握

 最初に結論ベースで話せと言われることがあるので最初にまとめておきます
useEffect: 副作用を扱う(コンポーネントのレンダリング以外の外部とのやり取り・状態の変更)ためのフック
副作用の例:データフェッチ、イベントリスナー登録・解除、DOM直接操作、タイマーの設定など
利点:useEffect内で副作用を実行することで、Reactのレンダリングフローを乱さずに副作用を管理できる

useMemo: 特定時点での関数の処理結果をメモ化(キャッシュ)するフック
useCallback: 関数オブジェクトをメモ化(キャッシュ)するフック

 内容まとめ
レンダー: コンポーネントが仮想DOMを生成するプロセス。

詳細: レンダリングは、Reactコンポーネントが自身の状態やプロパティに基づいて仮想DOMを生成するプロセス。これにより、UIの変更が効率的に管理される。


再レンダー: 状態やプロパティの変更により、コンポーネントが再度レンダリングされること。

詳細: 再レンダーは、コンポーネントの状態やプロパティが変更された際に、Reactが新しい仮想DOMを生成し、実際のDOMとの比較を行い、必要最小限で部分的にUIおよび関連情報を更新するプロセス。


関数定義のキャッシュ: クライアントサイドで関数オブジェクトを保持し、再レンダー時の再生成を避けること。

詳細: useCallbackを使用することで、特定の依存関係が変わらない限り関数オブジェクトを再生成しないようにしてパフォーマンス改善を図る。


 useMemoとuseCallBackで何が違うのか？useMemo
関数を呼び出した結果、戻り値をキャッシュする。特に計算コストが高い結果を、計算処理の元となる値を保持する依存関係(下記例コードで変数a,b)が変わっていない時に再計算する手間を省ける
下記コード:computeExpensiveValueの結果を、依存配列[a, b]が変化したときにのみ再計算
const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);
useCallback
関数オブジェクトそのものをキャッシュする
const memoizedCallback = useCallback(() => {
  doSomething(a, b);
}, [a, b]);
下例のように、特に関数がコンポーネントを呼び出す場合でコンポーネントが変わらない時、子コンポーネントを仮にメモ化しても関数がメモ化されてないと、メモ化されているものは残ったまま新しいChildComponentが作成され、メモ化する前より状況が悪化する可能性があるので関数もメモ化する
const ChildComponent = React.memo(({ onClick }) => {
  console.log('ChildComponent rendered');
  return <button onClick={onClick}>Child Button</button>;
});

function ParentComponent() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    console.log('Button clicked');
  }, []);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Parent Button</button>
      <ChildComponent onClick={handleClick} />
    </div>
  );
}

 useMemoとuseCallbackのプラクティス最小権限の原則と一緒でパフォーマンス改善系のロジック使用もトレードオフを考慮して最小化:
useMemoやuseCallbackのキャッシュ対象の処理コストが小さいとき、メモ化処理・メモ内容の比較処理・取得時I/Oコストによりキャッシュがパフォーマンス低下につながる
メモ化によるデータ量が多くなりすぎることでメモリ領域を多く消費し、キャッシュミスが多発するとパフォーマンスが低下

依存先、依存配列を必要十分に指定する
不必要な依存先を指定: 不必要にキャッシュ内容が再生成され、無駄な処理コスト発生
そもそもuse系のフックとは？ -> 依存先の変数を指定し、その変数の値または参照先の変数のアドレスが変わると内部の処理を実行するReactの標準関数。イベントハンドラが抽象化されて便利になってる感じ

純粋関数を使う
副作用のない関数を渡す:useMemoやuseCallbackに渡す関数は、副作用のない純粋関数にして、副作用処理の責任は専用のフックuseEffectに委任するReactの指定している暗黙のルールを守る
副作用のない純粋関数を使用することで、キャッシュ破棄時の予期しない動作によるバグやセキュリティリスクを避ける

子コンポーネントの最適化と組み合わせる
React.memoと組み合わせる:子コンポーネントがReact.memoでメモ化されている場合、親から渡す関数やオブジェクトをメモ化する


 useEffectとuseCallbackの使い分けによるパフォーマンス最適化
 余談effectという単語は、ef:外部+fect:なんかどこかしらに手で動作をするイメージ、なのでそれが定義されているスコープ外へと何かしらの影響を与える処理の責任を担当する、という感じがします

命名からそのソフトなどの開発者の意図を汲むことも大切です

 目的下記の初期コードにてroomIdが変わった時だけuseEffect処理が実行されるようにしたい

 初期コードcreateOptionsがメモ化されてないためroomIdが変わらなくても再レンダリング時、外部との接続処理が行われ、useEffectが無駄に発火し、同じデータ・UIが再生成されるfunction ChatRoom({ roomId }) {
  const [message, setMessage] = useState('');

  function createOptions() {
    return {
      serverUrl: 'https://localhost:1234',
      roomId: roomId
    };
  }

  useEffect(() => {
    const options = createOptions();
    const connection = createConnection(options);
    connection.connect();
    // ...
  }, [createOptions]);
}

 改善１useCallbackを使用、createOptions関数をメモ化して、roomIdが変更されたときのみ関数が再生成されて副作用が実行されるようにしましたfunction ChatRoom({ roomId }) {
  const [message, setMessage] = useState('');

  const createOptions = useCallback(() => {
    return {
      serverUrl: 'https://localhost:1234',
      roomId: roomId
    };
  }, [roomId]); // ✅

  useEffect(() => {
    const options = createOptions();
    const connection = createConnection(options);
    connection.connect();
    return () => connection.disconnect();
  }, [createOptions]); // ✅
}

 改善2改善1においてuseEffectがcreateOptionsに依存する関係を定義しなくても、依存配列にroomIdを直接指定することで、副作用がroomIdの変更時のみ実行されるようにリファクタリングしましたfunction ChatRoom({ roomId }) {
  const [message, setMessage] = useState('');

  useEffect(() => {
    const options = {
        serverUrl: 'https://localhost:1234',
        roomId: roomId
      };

    const connection = createConnection(options);
    connection.connect();
    return () => connection.disconnect();
  }, [roomId]); // ✅
}

 useEffectとuseCallback比較まとめより良いプラクティスが存在すると思いますが、この程度で一応整理できたかなと思います。

useEffectとuseCallbackを使用して実際にコードを書く練習をしました。

 docs・技術記事キャッチアップまとめdocs・技術記事からのキャッチアップのまとめとしてはここで終わりにします。

ここまでで３時間ほどでした。

Reactのdocsがとても綺麗にまとまっていて勉強しやすかったです、また、同時に以下の技術記事からも学ばせて頂きました。とてもわかりやすく勉強になりました。ありがとうございました。
https://qiita.com/soarflat/items/b9d3d17b8ab1f5dbfed2

https://zenn.dev/maktub_bros/articles/da94649de294f3

https://zenn.dev/chot/articles/react-when-to-use-memo
ここでですが、一番下の記事を拝見した際に、自分の認識が間違ってるかもしれないと感じたため、内部をきちんと把握するためdocsを改めて見に行きました。が、docsは、Reactなどを利用する開発者が、内部実装の詳細が抽象化されていてもAPIを利用できるようにするためのものだったので実際のossを見に行きました。

 OSSコード調査　- 事実ベースを担保するためにOSSコード本体を見に行こう（ステップバイステップ）
 目的use系のフックの状態管理の内部ロジックがどうなっているのか、そして高速化のロジックも肌感覚(？)的に知りたい

 下記まとめ全体の方針著作権やライセンスに配慮し、OSSのコードの詳細がわからない範囲でシンボル等の指示をし、理解した内容やプロセスを自分の言葉で要約・解説しています
まず初めにプロジェクト内を調べた結果
https://github.dev/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberHooks.js
にuseMemoの実装があるっぽいので見てみると、useMemoの検索にヒットする部分が多いです。

ここで、Dispatcher - HooksDispatherOnRerender変数のuseMemo変数に関連づけられているのがupdateMemoというシンボルでした。

ここで変数名的に内部のフック関連の情報を管理するのに利用するディスパッチャ(一般的に有名なデザインパターンだと思います)であり、アップデート処理に利用するものというのがわかりました。

　

　次に、アクションタイプによって詳細や実装方針は大体同じ感じのはずなので特殊ケースupdateMemoの詳細を見に行けばいいかなという感じになります。よって、updateMemoを見てみるとnextDepsやprevState、そしてhookとしてupdateWorkInProgressHook()が処理として切り分けられています。なので、updateWorkInProgressHookを見に行きます。すると、内部にcurrentlyRenderingFiberというシンボルがあります、fiberというと繊維というイメージがあり、ここから何かと何かを繋ぐ存在かなというのが推測できます。ここで一旦まとめておくと、内部実装的にidのようなものは振られていないので、React内部ではコンポーネントや状態フック1つ1つに一意なidのようなプリミティブな値を振っていなさそうだな、という予想がつきます。
またここで、Hook型が気になったので型定義を見にいくと(同一ファイルで管理してるんですね)、状態を保持しておくためのqueueと(これがコンポーネントに関連づけられた状態を管理するものっぽいです、Reactでは状態を内部で管理している連結リストのようなオブジェクトの参照順序で一意性を担保してるみたい)あとはbaseなのでデフォルト値、memorizedStateなので現時点で参照してる値を保持するフィールド、そして、nextメンバに関してはHook型なので連結リストみたいな感じのやつを採用しているのはほぼ確定かなと思います。
さて、話に戻り、

fiberというシンボルが気になったので定義を見に行きます。すごくわかりやすいですが、

https://github.dev/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberHooks.js

にあるようです。ファイル名的にたぶんそうかな(？)みたいな感じです。

上から見ていくと
export type {Fiber};
があるので型定義情報を確認します。ファイル行数が1,000行もないので少なくてありがたい...と思いつつ見ていくと、FiberNodeの管理メソッドやメンバ定義などの処理を管理しているファイルみたいで、どこかにステート管理するFiberNodeとReactコンポーネントの接続情報を管理するところがあると思うので、当てがはずれたみたいです。他にもパラパラファイルを見て行きましたが、１つ１つのファイル行数が多いので手間です。

よってシンボル検索をかけたいと思います。
currentlyRenderingFiber
を用いて検索をするとReactFiberHooks.js・ReactFiberNewContext.jsファイルでシンボル名がヒットしました。
ただここで、先ほど見ていたReactFiberHooks.jsにおいて
currentlyRenderingFiber = workInProgress;
という行を見つけたので、workInProgressを見てみるとFiber型が割り当てられていてrenderWithHooksなどの関数内部で使用されているみたいです。

renderWithHooksという関数が気になったため、参照先を見てみると、ReactFiberBeginWork.jsファイル内で使用されているみたいです。

上の方から見てみて、reconcileChildrenという関数がありますが、これはおそらく仮想domか何かのコンポーネントを比較して効率的にdomを更新する処理部分を提供してそう、というのが命名的に想定されます。

　ここで、現在のファイルは

https://github.dev/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberHooks.js

です。
reconcileChildren内部では
mountChildFibers
reconcileChildFibers
の2つの関数があり、マウントの方に関しては「ファイルマウント」と同じ要領で、異なるインスタンス同士を何かしらのインターフェースで情報・アクセス的に接続を図る、という感じなので、初期化っぽいことしてるんだなー、という感じです。

　次に、reconcileChildFibersの方を見た方がマウントの方の基本実装も推測できそうなので見てみます。

　引数にLanesというのがありますがこれは、レンダリングの優先度・種類を示すビットフィールド、らしいです。PC内部のレジスタ・Assemblyを使用した開発時の話になりますが、レジスタの状態を表現する際のビットと同じ要領ですね。

　色々と再帰的に見に行ってみると、ReactFiber.jsにcreateFiberImplObjectという関数があり、これはFiberを作成する関数っぽいです、内部で、enableObjectFiberというのがあり気になったのでインポート文を見てみるとフラグみたいです。こちらの探索は一旦ここまでにしたいと思います。
また、ReactChildFiber.jsファイルにて、createChildReconciler関数があり、内部を見てみるとポインタを用いて子要素を削除しているdeleteRemainingChildren関数やmapRemainingChildren関数があります。ここで、mapRemainingChildren関数はmap構造を利用してFiberノードへのアクセスを高速化しているようです、ここでの目的はReactコンポーネントとFiber、use系が扱うステートとの連携部分を見つけることなので関係なさそうですが、こういった改善部分の実装にも目を向けると全体の実装ロジックの方針が見えてくることもあります。方針として一貫しているところはやはりプロという感じがしてすごいなと思います。

さらに探索を続けると、useFiber関数がありこれもmapRemainingChildrenと同種です。
ここで、
fiber系のシンボルから探しても見つからなそうなこと
今回のReactコンポーネントとuse系の状態管理は、
Reactコンポーネント
Fiber
use系が扱うステート

の3つから構成されていそうだということがわかったので探索の視点を変えて、Reactコンポーネントの命名で使われていそうなシンボルelementが見てる中で見つかったので検索に使用します。

見てみるとupdateElement関数が見つかりました。ビンゴです！

関数の引数に、FiberとReactElementがあり、Reactコンポーネントの背景では、Fiberを通じてuse系が使用するステートにアクセスする連結リスト構造になっていることがわかっているのでたぶんこの関数かな(ビンゴというのは早いかも)という感じです、見ていくと、createFiberFromElementという関数があり、さらに定義を辿ると、ReactFiber.jsのcreateFiberFromTypeAndPropsという関数がありました。この関数の内部実装を見ていくと、引数部分にまずtypeがありそれをif文の判定文内で使用しているので分岐処理を行う際の判断指標となるデータであることがわかります、そして、各分岐処理内容を見ていくとfiberTag変数にref,lazy,contextという状態データを格納したり(それぞれ種類別に適切な処理が違うので分岐している感じだと思います)、createFiberFromTracingMarkerといった適切な形式を持ったFiberを作成する処理を実装していることがわかります。

なお、createFiberFromElementのreferenceについては見ればすぐわかるので省略です。

 OSS内部仕様調査まとめここまでの内容から、スコープやタグなどでFiberを分類したりすることがわかりました。

調べる中でわかった内容を下記にまとめておきます。
React: キーとスロットを組み合わせて、最小限の更新でUIを再描画
Fiberノード: Reactが内部でUIを効率的に保持・更新するための連結リストを利用したステータス管理データ構造、各コンポーネントの情報を保持、仮想DOMを効率的に管理・更新するデータ構造体
タイプに応じて、適切なFiberのタグ(fiberTag)を決定
必要に応じて特殊なFiber(フラグメントやサスペンスなど)を作成して処理ロジックを細分化
レンダリング作業を小さな単位に分割し、非同期的に処理することで、ブラウザのメインスレッドをブロックせず、ユーザーの操作に素早く応答可能
Hooksを使用する関数コンポーネントの場合、Hooksの状態もmemoizedStateに格納
副作用はコミットフェーズでまとめて実行
各作業に優先度を設定し、緊急性の高い更新を優先的に処理することでUXの向上を可能にしている
コンポーネントの種類(関数・クラス・ホストコンポーネントなど)に応じて、Fiberを生成
Fiber内部構造・役割

内部:
type: コンポーネントのタイプ(関数、クラス、文字列など)
key: リスト内で要素を一意に識別するためのキー
child: 最初の子Fiberへの参照
sibling: 次の兄弟Fiberへの参照
return:　親Fiberへの参照


Fiberはツリー構造を形成し、Reactコンポーネントがレンダリングされる際そのインスタンスの情報を保持する役割を果たす
調停(Reconciliation): 現在のFiberツリーと新しい要素(仮想DOM)を比較、差分を検出・適用・必要に応じて作成する処理、メインとなる関数はreconcileChildren、reconcileChildFibersあたり
createFiberFromTypeAndProps: 与えられたコンポーネントタイプ(type)とプロパティ(props)から新しいFiberを作成
全体の概要としての処理フロー・責任分離確認
Reactコンポーネント: renderメソッド・関数コンポーネントとして、仮想DOMを返す
仮想DOM: 実際のDOMの軽量なコピー、UIの状態を表現
調停プロセスを通じて、新旧の仮想DOMを比較し、差分検出(Fiberアーキテクチャモデルで効率化)
レンダラー(react-domなど): 検出された差分を実際のDOMに適用、最小限のDOM操作により、パフォーマンスを最適化しつつ、UIを更新



 用語集
Fiberノード: Reactが内部でUIを効率的に保持・更新するための連結リストを利用したステータス管理データ構造。各コンポーネントの情報を保持し、仮想DOM（Virtual DOM）の効率的な管理・更新を可能にする。

調停（Reconciliation）: 現在のFiberツリーと新しい要素（仮想DOM）を比較し、差分を検出・適用・必要に応じて新しいFiberを作成するプロセス。

仮想DOM（Virtual DOM）: 実際のDOMの軽量なコピーで、UIの状態を表現する。

メモ化（Memoization）: 計算結果をキャッシュし、同じ入力に対して再計算を避ける手法。

React.memo: 高階コンポーネントで、プロパティが変更されない限り再レンダリングを防ぐ機能。

useCallback: 関数オブジェクトをメモ化するフック。再レンダー間で関数定義をキャッシュし、不要な再生成を防ぐ。

useMemo: 計算結果をメモ化するフック。依存関係が変更されない限り、計算を再実行しない。

useEffect: 副作用を扱うフック。コンポーネントのレンダリング以外の外部とのやり取りや状態の変更を管理する。

 終わりに今回、Reactについての理解を深めるために、技術記事・公式ドキュメント・OSSコードを調べ、学ぶ過程を記事にしました。次回の記事では、カスタムフックの作成を詳細設計を考えながらステップバイステップでまとめる予定です。

　Reactはまだわからないことも多いですが、今後も勉強を続けていきます。長文になってしまいましたが、お読みいただきありがとうございました。
追記：下記の記事を後から知って、とてもみやすくまとまっていました。引用失礼致します。

https://zenn.dev/ktmouk/articles/68fefedb5fcbdc
Discussion

Meguri
useMemoやuseCallbackをどう活用すべきかについての解説がとても参考になりました。これらのフックを適切に使うことで、パフォーマンスの最適化に大きく貢献できると感じました。
yuto
コメントありがとうございます!
自分も改めてきちんとドキュメントを読むことで学びがたくさんありました。
今後も勉強を続ける中で質の良い記事を書けるように心がけていきます!
初めに

この記事から学べること

NOTE

目的の確認

今回、実際何をしたか

所要時間

初期位置の確認

最初にしたこと

意識しておいた方が良さそうなこと

業務的な開発Tips

キャッチアッププロセス

docs読み込み・技術記事参照

最初に

内容まとめ

useMemoとuseCallBackで何が違うのか？

useMemoとuseCallbackのプラクティス

useEffectとuseCallbackの使い分けによるパフォーマンス最適化

余談

目的

初期コード

改善１

改善2

useEffectとuseCallback比較まとめ

docs・技術記事キャッチアップまとめ

OSSコード調査 - 事実ベースを担保するためにOSSコード本体を見に行こう（ステップバイステップ）

目的

下記まとめ全体の方針

OSS内部仕様調査まとめ

用語集

終わりに

Discussion

OSSコード調査　- 事実ベースを担保するためにOSSコード本体を見に行こう（ステップバイステップ）
