Upgrade to Pro — share decks privately, control downloads, hide ads and more …

React改造してみた

 React改造してみた

Giza.js #12 で登壇した際のスライドです。
React の reconciliation プロセスを改造することで、クライアントでも非同期コンポーネントを書ける新たな計算モデルを作成しました。

Avatar for Mooncake Sugar

Mooncake Sugar

October 19, 2026

Other Decks in Technology

Transcript

  1. 2 Mooncake Sugar (糖衣月餅/つきもち) 26新卒 Android書いてます @渋谷 Ginza.js の銀座でも JS

    でもない部分 Neovim と Deno が好きです 人生初登壇です Modding React / Mooncake Sugar
  2. 4 非同期コンポーネント バックエンドや DB アクセス・最近の Web API はだいたい非同期 React のコンポーネントは関数

    当然非同期関数の React コンポーネントも書きたくなる Modding React / Mooncake Sugar
  3. 7 一般にクライアントで非同期コンポーネントは使えないが...... React 19 では ReactNode として Promise も受け付けている Definitely

    Typed の型定義でも許容されている React Fiber の機能としてはクライアントでも
 非同期コンポーネントを使える (はず) Modding React / Mooncake Sugar
  4. 9 なぜ繰り返し再描画が行われるのか? (render開始) work loop beginWork 再スケジューリング updateFunctionComponent renderWithHooks →

    Promiseが返ってくる reconcileChildren → SuspenseException を投げる completeWork commit 描画するたびに非同期コンポーネントが Promise を生成 → SuspenseException のループ Modding React / Mooncake Sugar
  5. 12 関数コンポーネントのモデル (何回も気軽に再レンダリングされる) を考えると当然 必要な場合にだけ非同期処理を実行してほしい 古の手法 useEffect + useState 現状あらかじめ直交化して

    use を使って Promise を剥がす方法に落ち着いている barPromise は foo が変わってもじインスタンス SuspenseException を投げる場所が use フックになった Modding React / Mooncake Sugar
  6. 13 We strongly considered supporting not only async Server Components,

    but async Client Components, too. It's technically possible, but there are enough pitfalls and caveats involved that, as of now, we aren't comfortable with the pattern as a general recommendation. The plan is to implement support for async Client Components in the runtime, but log a warning during development. The documentation will also discourage their use. 
 The main reason we're discouraging async Client Components is because it's too easy for a single prop to flow through the component and invalidate its memoization, triggering the microtask dance described in an earlier section. It's not so much that it introduces new performance caveats, but it makes all the performance caveats described above much more likely. 要約 技術的には可能だが、多くの落とし穴があるため現時点では非推奨 プロパティの変化でメモが無効化されやすい Modding React / Mooncake Sugar
  7. 20 改造方針 Promise のメモ化は React Compiler に任せる (memoCache) サスペンドしても memoCache

    を保持するようにする 初回レンダリング・更新時の両方 (保証はされていないが実際の挙動として) ほとんどの場合メモは再レンダリングを超えて
 保持されるので、それに依拠する Modding React / Mooncake Sugar
  8. 21 改造ポイント 初回対策: suspend したときにサブツリーを Offscreen に退避してキャッシュだけ再利用 更新時対策: enableNoCloningMemoCache の有効化

    current tree / WIP tree 間での memoCache のコピーを無効化する実験的フラグ WIP tree で memoCache に書き込んだあとに中断してもキャッシュが残るようになる async function → function + use への変換 babel plugin で機械的に変換 Modding React / Mooncake Sugar
  9. 23 改造結果 未実装 useMemo, useStateの保持 入れ子の memo, Suspense 分岐内の await

    などなど 難しそうなもの もし何かしらの要因で前回のレンダリングでのfiberとマッチしないことがあったら
 非同期処理はもう一回走ることになる ループ内の await, for await async の try...catch useTransition, useDeferredValue, ... hydrateRoot や react/server, react/static のレンダリング などなど Modding React / Mooncake Sugar
  10. 24 まとめ この実験は式の依存性を解析して再計算を排除するというモデルを
 React の世界に導入するという意味で破壊的 この思想が好きかどうかはかなり好みが分かれそう Server Components は Clients

    Components と思想が違い、
 1回きりの計算だから非同期処理という副作用を取り込めているが、
 メモ化を強力にすることでこれらの思想の橋渡しができそうと
 考えると面白くないですか? Modding React / Mooncake Sugar