次世代 React CSR SPA 開発 学習メモ
MasuqaTReact 18 で Concurrent Rendering が実現される。これを使う実装パターンやライブラリが整った状態を当面の次世代と位置づけ、そこに向けて現在の React SPA 開発からの差分をキャッチアップしていく学習のメモをここに残す。
（SSR や ISR はメモ作成者の興味対象外なので特に触れる予定はない）
MasuqaTこのスクラップが固まる前に追加されたような Web 標準機能は取り入れる。
MasuqaTSuspense を、ボイラープレート的に使ったりそれをコードレビューで確認するような、普段の実装の 8 割程度を占める難度の内容を理解するので十分であれば、サマリ的なこの文書を読めばよい。
差分
- 読み込み処理は
isLoadingのような状態でなくSuspenseで宣言的に表現できる - 複数コンポーネントをまとめてサスペンドできるため、複雑な表示制御は手続き的処理より簡単に書ける
MasuqaTSuspense の処理を学ぶにはこのハンズオンが良い。実装パターンやライブラリの使い方を軽く読むのに十分なレベルの知識が得られるはずだ。
差分
- ローレベルでは、コンポーネント内処理で Promise を
throwして Suspense で受け取るという流れになる - Suspense という概念の導入によりコンポーネントのステートに注意事項が増える
- Suspense は（CSR では）主にサスペンドの境界を定める
- render-as-you-fetch パターンが（ある程度実現しやすい形になって）登場する
MasuqaTrender-as-you-fetch パターンは、手前味噌な概念だが「犠牲的モジュラフロントエンド」 https://zenn.dev/occar421/scraps/a02ac7b40c0df1 の実現に大きな役割を持つと考えている（fetch の物理処理と論理処理の間をいい感じにやるライブラリはさらに必要）。
MasuqaTSuspense を使いこなすところに到達するにはこのハンズオンが良い。Suspense によりより良い UX を提供するための知識が得られるはずだ。
差分
- トランジションという優先度の低いステート更新という概念ができる
- トランジションは「表の世界」でなくまず「裏の世界」（平行世界）に反映され、終わり次第「表の世界」に現れる
- 実際にはトランジションは記録され、「表の世界」が変わるたびに毎回「裏の世界」（平行世界）が生成される
-
useTransitionから得られるstartTransitionとisPendingにより、トランジションさせるための関数とその処理中のフラグのペアが得られる
MasuqaTどこかに載っていたのか、それを見て自分で思いついたのかは不明なこと。Suspense の概念の捉え方について。
- 「Suspense=読み込み処理」や「Suspense=（変数としての）読み込み中フラグが不要」という捉え方ではかなり不十分
- Suspense 自体は処理を待つ（サスペンド）という結構抽象的な概念
- 今まではフラグなどの変数と手続き的な処理で実現していたがこれが変わる
- 何の理由で待っているかは Suspense 部分は知る由もない
- その一番わかりやすい具体例として、読み込み処理が終わるまで待つ、という例が頻繁に紹介される
- すべてのコンポーネントはサスペンドする可能性がある
- 今までは読み込み処理が終わるまで待つことをフラグで表現すると局所的だったがこれが変わる
- どこが読み込むか（局所性を）考えるのは不要になるが、逆に、常にどこでも考えるべき観点になった
- Suspense 自体は処理を待つ（サスペンド）という結構抽象的な概念
- ErrorBoundary と似たようなもの
- こちらも（最終ゲートとしてでなく）Suspense のような使い方で積極的に使っていく可能性がある
- データ取得コードと取得後の表示コードの近接の効果は無視できない
- 親で data を渡してくるのも動くには動くが一度に読むべきコード量が増えてしまう
MasuqaT末端までのどこでデータ取得処理があるかは気にする必要がなくなる。
これは、設計上、データ取得ライブラリの特性と相乗効果がある。
MasuqaTrender-as-you-fetch を実現しやすくなる（と筆者が予測している）GraphQL の利点などはこの記事でおさらいできる。
MasuqaTRESTful API だったり Redux だったりを使い、よく考えていればそれらでも render-as-you-fetch は可能ではあるだろう。
React Location のようなルーターを使う手もあるかもしれない。
MasuqaTGraphQL の Fragment Colocation とその自動巻き上げ（希望的には Location に応じた root での必要最小限集合の fetch）が利用できるのは大きいと思う。
MasuqaT自分がイメージする自動更新判定のは urql まんまだった。
MasuqaTバックエンドを含めて考えた時のメリットは、この記事を見れば OK。
MasuqaTrender-as-you-fetch はここが整理されていると思う。
- fetch-on-render, fetch-then-render, render-as-you-fetch の違い
MasuqaT「コンポーネント A はロケーション B の時にデータ C を要求する」ことが事前に解析できれば、コンポーネントが render される前に読み込みが走り render が走りサスペンドし、随時表示されていくのでうれしいはず。
Fragment Colocation で推奨されるような GraphQL と React とでそれぞれ import する鎖を活用すれば良さそうではある。ただし、useFragment のようなものは Suspense 実現のために必要になる。
export const PetPageGql = gql`${PetQuery}`;
export const PetPage() {
const [initialQueryRef] = useSomething();
const [petReference] = useQueryLoader(PetPageGql, initialQueryRef);
return <Pet reference={petReference} />
}
export const PetQuery = gql`query Pet {
pet() {
name
...PetDetail
}
${PetDetailFragment}
}`;
export function Pet({ reference }) {
const { data: { pet: { name } } } = usePreloadedQuery(PetQuery, reference);
return <div><span>{data.name}</span><PetDetail reference={reference} /></div>
}
export const PetDetailFragment = gql`fragment PetDetail on Pet { description }`;
export function PetDetail({ reference }) {
const { data: { description } } = useFragment(PetDetailFragment, reference);
return <p>{description}</p>
}
fetch-on-render
イメージ
MasuqaTfetch-then-render
イメージ
MasuqaTrender-as-you-fetch
イメージ
<Suspense fallback={<div>foo-bar</div>}>
<Component data={data} />
</Suspense>
これをやると GraphQL をクライアントで使う感じがつかめそう。Fragment Colocation も。
Fragment Colocation はメモの筆者のイメージと違い、機能やライブラリではなくファイル構造設計に近いような話だった。大きく構えすぎていた。
MasuqaTサブコンポーネントでの useFragment 相当の取得方法ができて初めて Fragment Colocation が本領を発揮しそうだし、render-as-you-fetch も理想に近づきそう。
MasuqaTGraphQL で出てくる概念諸々
"GraphQL Federation"
現状は Apollo での実装（Apollo Federation）しかない？
メモ作成者の現在の状況からすると必要ではないので、自分では深追いはしないでおく。
Persisted Query
感じたメリット
- 意図しないクエリを封じる
- リクエストのペイロード量の削減
感じたデメリット
- 登録クエリ管理が難しそう
- API リクエスト時のオンデマンドなクエリ変化という利点が失われてしまうのではないか？
Apollo の Automatic Persisted Queries は面白そうだった。一応、意図しないクエリで負荷がかかる課題は Query depth, Query complexity, Query rate limit の制限である程度緩和できるはず（リンクは後述）。
MasuqaTとりあえずはライブラリやサーバーが良しなにやってくれると信じて、フロントエンドではこれらは検討しなくていいんじゃないかな…最適化段階か何かでちょっと弄れば大丈夫そうだし。
MasuqaT(TODO)
production ready react 18 + graphql
他にも GraphQL の資料はあるはず
海外の有料の資料（Production Ready GraphQL）
エラーのリソース定義のブログ記事（社の Slack にリンクがあるので探せばリンクは見つかる）
React 18 の Production Readiness はどう考えればよいのだろうか。
MasuqaT(TODO)
一応はバックエンドの GraphQL サーバー事情も少々…
MasuqaT何故かわからないが、GraphQL のクライアントライブラリとして、触る前から Apollo はなんか違うという気がしたので後回しにする。Meta 謹製の Relay か urql を触ってみる。
React Suspense や Fragment Colocation を使ったときに便利なものを見つけ出したい。
（TODO）
- relay
- gqless 🤔
- urql
MasuqaTコード生成も重要なのでチェックする。こちらも React Suspense や Fragment Colocation を意識する。
(TODO) 例えば以下。自作でもいいのだろうが、ユースケースはどこの開発案件でも近いはずで共通化しやすい部分だと思うので、なるべく OSS を活用したい。
MasuqaTそもそもの Data-Fetching ライブラリを使う利点。
※ 下記記事にまとめた
ライブラリの書いてある推しポイントでない、設計上の優位性が確かにあると思うのだが。あまり触れている記事が無い。GraphQL クライアントには Data-Fetching ライブラリの機能を（特に区別せず）統合しているものもあるため、それも調べてみる。
Suspense の登場によって Organisms 単位でデータ取得しても読み込み状態の表示がちぐはぐになるわけでなく、（それを使う）Pages 単位で好きなまとまりに対していい感じに見せることができるようになる。以前はちぐはぐになるか Ornganisms - Pages 間で密にデータをやり取りしないといけなかっただろう[1]。
-
上に読み込み状態を好きに制御させるのが大変。こういうことが起きる中間管理職的なコンポーネントとその設計は今までしてなかったので実際はわからないが…。 ↩︎
MasuqaTAPI エンドポイント間の依存性の表明の問題の解決を OpenAPI 等＋コードで書くのでなく GraphQL Scheme に書くことに求める前提なら、設計上の利点を求めるときに思想と一番合うのは Relay ということになるだろう。
MasuqaTRecoil は全くわからないが、API エンドポイント間の依存を解決するのは Recoil のデータフローグラフと相性がいいかもしれないし、（recoil-relay がある GraphQL は置いておいて）REST API でも（コードとしてあらわすことになるが）Recoil を使うといい感じに解決してくれるかも。
Mutation で atom を弄ると effect で関係する Query の atom に働きかけてその atom が再読み込みされるとか（Recoil エアプ）
MasuqaTAPI エンドポイント "等" からキーを生成、そのキーを基準に依存関係を記述して、更新処理でキャッシュを invalidate する。「API エンドポイント＝キー」だと痛い目に遭いそう。
MasuqaT（TODO）
ルーティングライブラリ
React Router v6.4 とか React Location とか。
render-as-you-fetch を実現する仕組み、もしくは、パラレル読み込みを実現する仕組み。Page の loader を export してルーティングコンポーネントに何を読み込むかを事前に表明することで実現する。Fragment Colocation を想起させるのはないこともない。
MasuqaTConcurrent の文脈で、React か何かがすべて読み込み先を自動収集してくれるといいんだけども。もしくは、単一 useQueries を export しておくとか。
MasuqaTRecoil 等のデータフローグラフ
※ 下記へ切り出した
MasuqaTRecoild の Atom の default の初期化方法で Promise を使う場合の違いについて。
ファイル読み込み時に問答無用で読み込むか、必要になったら読み込むか。
MasuqaTRecoil で React Query っぽいのを作るとこんな感じなんだろうか。（一度も動かしてないので多分動かない。）
MasuqaT↑ useRecoilRefresher ですごく楽に書けそう。default: selector({}) を発火させられるので。
P.S. これは atom には効かない。selector に効く。atom に reset を使うと default の値に戻るだけで、default に書かれた処理が発火することはない。
MasuqaT
すでに recoil-query は出来上がっているのでは…
MasuqaT順番は分からないが、Server State 専用だったデータ取得ライブラリを抽象化して Global State に全体適用したのが Recoil だろうか。
MasuqaT値のセットされていない atom の値を参照すると Suspend する。
MasuqaTreact-query 風になるよう乱暴なコードを書いてみた。（キャッシュキーは配列でなく文字列）
使い方
こんな感じで包むと、気軽に Server State を扱える気になるが、Global State とのつながりが失われてしまい、わざわざ Recoil で裏を作る意味がなくなってしまう。Atom や Selector は export するようなインターフェースにしたい。（API は react-query と全く違うものになるため、recoil-query という名前ではない方が良いだろう。）
MasuqaTatom effect により、State 利用者は技術的詳細を知らなくて済む。infrastracture 的コードの部分で勝手に裏を入れ替えることが可能。
単なる JavaScript メモリー上の Client State を、LocalStorage に永続化するようにする場合、atom の定義場所で atom effect を書けば事済む。
きれいな関心の分離。データノード定義と利用ソースの分離。
MasuqaTこれ以降の Recoil による Server State 管理の実現は下記へ。
MasuqaTCSS Cascading Layers そのものと React での活用
MasuqaTおそらく下のように分ければいいのではないだろうか
- reset: リセット
- design-system.base: デザインシステムの基礎スタイル
- design-system.component: デザインシステムのコンポーネント
- base： （有れば）アプリケーション固有の基礎スタイル
- piece: アプリケーション固有の小規模コンポーネント
- area: Atomic Design での Organisms レベルコンポーネント
- page: ページコンポーネント
- app: アプリケーション
MasuqaT単純に、reset 層以外はコンポーネント階層やディレクトリ設計に従えば良さそうなので、そちらを先に考えることにする。
CSS Cascading Layers が入ってもそんなに書き味や設計は変わらないだろうというのもある。
MasuqaTMasuqaTTailwind みたいな utility の層をどこに置くかという問題はあった。
そもそも使うのかどうか、使うべき属性は何か、という議論はあるが…
MasuqaT（TODO）
Headless components
デザインシステムとかの共通コンポーネント層にもつながると思う。
MasuqaT（TODO）
Container Query とか :has() セレクタによるコンポーネント CSS の書き方の変化