168iroha
commented
9 months ago 現状のハイドレーションの仕組みの整理
- コンポーネントに基づきDOMツリーを親から順に構築（SSR）して、それに対してハイドレーションを行う
- 不定な外部からの入力や乱数といった副作用が存在するとSSRで構築したDOMとハイドレーションを行う際に構築されるDOMノードに差異があるとエラーとなる
- SSRで構築したDOMツリーは子コンポーネントからの状態の変更の振る舞いや非同期処理といった副作用の影響が除去されている
- ここでの副作用はコンポーネントを示す関数が
propsとchildrenを入力としてコンポーネントを示すノードのツリーを出力する関数とみたときに副作用とみなせる操作を指す - そのため、子コンポーネントの構築で親コンポーネントに影響を与える操作は副作用とみなされる
- ただし、状態の変更であっても状態変数の変更のみは許容する（DOMノードの変更は許容しない）
- ハイドレーション時は副作用の影響はハイドレーション完了まで遅延される
- 副作用の制御については
sideEffectLabelというラベルにより行っている
- ここでの副作用はコンポーネントを示す関数が
- 同期的にDOMツリーは構築される
ハイドレーションの改修案
- DOMツリーの構築を非同期に行うようにする
- どう考えても副作用の条件を緩めるとハイドレーションでバックトラックをする必要が生じてしまうためNG
- 非同期といっても非同期データの取得が完了するまで待機を行うためのもの
- ハイドレーションの際はSSRで取得したデータを取り出すため待機はしない
- SSRで非同期処理を行った結果はハイドレーションの際に参照を行うDOMノードの子に記述する
例として、以下のように
useSSRDataによりSSRで非同期処理を行った結果を得る場合、function Component(ctx) { const data = useSSRData(ctx); return $('div', { style: data }, ['sample']) }SSRでは以下のようなDOMツリーが得られるようにする
<!-- 従来の結果 --> <div style="">sample</div> <!-- 改修案における結果 --> <div style="width: 50%">sample<script class="useSSRData">{ "width": "50%" }</script></div>ハイドレーションを行うときには以下のようにSSRに関するDOMノードを除去する仕組みさえ用意しておけば、複数の
useSSRDataを行っても問題ない<!-- ハイドレーション後の状態 --> <div style="width: 50%">sample</div> - DOMツリーの構築を非同期に行う部分はコア機能として改修をして、
useSSRDataはライブラリとして与える - （ページ切り替えや非同期コンポーネント等により）初回のDOMツリーの構築で構築されない対象が
useSSRDataを用いていると、子要素の構築が遅延されてしまうため、遅延しないような評価の仕組みが必要- 現状の
GenStateNode.#mountImplでGenStateNode.mountによる構築とみなせるかGenStateNode.writeによる構築とみなせるかという区別ができるようにすることで対処可能 - ただし、これは
GenStateNode.mountとGenStateNode.writeとでuseSSRDataに関する評価順序が入れ替わる可能性があるため、用途はSSRなどと限定する必要がある
- 現状の
まずはやりたいことだけ整理しておく
背景
要件の整理
※その他、非同期処理の結果のキャッシュの有効期限等の議論も必要だが、本件は非同期処理を行うことが本題であり、いつサーバで非同期処理を行うかは本題ではないため、明示的に取り扱いはしない。ただし、それを可能とするインターフェースの整理は必要