• https://knowledgework.connpass.com/event/285601/

video

Suspense Fetchを3年実用してみて

• Fetching libraryの登場により
  • 今まではトップレベルのコンポーネントでfetchして、データを親から子に流していた
  • → 各コンポーネントが自分の関心のあるデータを取りにいけるようになった
    • コンポーネントツリーの末端からもfetchしやすくなった
• suspenseによる変化
  • isLoadingとerrorがコンポーネント外へ
    • isLoading → <Suspense fallback={<LoadingSpinner />}>
    • error → <ErrorBoudary />
    • → errorやloadingがより直感的にわかる。
    • → 要素を自由に囲むことで、表示内容を柔軟に指定可能。
  • T | undifined → Tへ
    • 例外処理が不要になり、正常系に集中しやすくなる
• 良い点
  • コードの見通しが良くなる
  • パーツ単位でloadingやエラーの機能を独立して持てるので、シンプルに実装可能
• 課題（２つとも正解がまだない）
  • waterfall問題
    • Suspense Fetchを2つ以上呼ぶと、直列実行になってしまい、1つ目のfetchの完了を、2つの目fetchが待機しなければいけない
      • 暫定として、read()という関数を挟むことで、fetchとsuspenseのタイミングを分離することで対処している
  • fetch on render問題
    • renderされたタイミングでfetchすること
    • コンポーネントを跨いで親子でそれぞれfetchする場合も、waterfallのように直列でfetchする問題が発生してしまう
      • 対処法：prefetch、子側でread()する、ただし関心分離がされない

---

React/Next によるアプリケーション開発のこれから

• 最近のReactの変化
  • Suspense
    • fallback
      • 詳細は前のセッション参考
    • Streaming
      • 徐々に読み込みが完了したものから順次段階的に表示すること
  • RSC
    • Serverだけで実行される新しいコンポーネント
      • ローカルマシンやCIでの実行も含む = Clientで実行されない
      • ReactTreeとして返却することにより、Clientで差分更新可能
      • サーバー側なので、filesyste、db、秘密情報等サーバーリソースにより扱える
    • SSR + RSC可能
    • clientコンポーネント=親、RSC=子供という構造も可能
    • RSCとRCCそれぞれできることが異なる
    • SSR
      • HTMLをサーバで生成
    • RSC
      • ReactTreeを生成
    • RSCでのデータフェッチング
      • Deduping（重複排除）
    • 依存関係がある場合はウォーターフォールは避けられない
      • 依存関係がなければPromise.allなどで解決できるが
      • PageLoadにおけるレイテンシ
        • ブラウザ - サーバ間はレイテンシが大きくなる
        • サーバ - サーバ間はレイテンシが小さくできる
    • フェッチングライブラリのソリューションが今後RSCにも輸入されていく？
      • 現時点ではクライアントのみになるため、統一されると嬉しい（個人感想）
    • Server Action(Alpha)
      • Server上で実行される関数をformやclient componentsにそのまま渡せる仕組み
      • 実際にはクライアントからサーバにリクエストが発行され、サーバ上で関数が実行されるため、クライアントに実装が漏れることはない
      • revalidatePath
        • 特定のパスに関連付けられたデータを再検証
        • https://nextjs.org/docs/app/api-reference/functions/revalidatePath
      • new Hooks（Ecperimental）
        • useOptimistiic
          • Optimistic Update（楽観的更新）
            • APIのレスポンスを待たずに想定する結果を画面に反映し、ユーザ体験の向上
        • useFormStatus
          • フォームの送信状態などの取得
• Next App Router
  • RSCを含むReactの新しい形を実装したフレームワーク
  • React自身がフレームワークを提案するように、フレームワークを使う世界線へ
• これまでとの考え方の違い
  • アプリケーション全体がReact Tree化
    • RSCによりサーバにまで拡大
    • ウォーターフォールの軽減

• JavaScriptを使わない表現
  • RSCとRCCを使う上でJS以外の選択を知っておくことは重要
  • CSSやHTMLだけで表現できるものは増えてきている

Live Coading Section（49:31〜）

https://www.youtube.com/watch?v=wRfp6198trs#t=49m31s

---

ナレッジワークでの App Router のこれまでとこれから

• 新規事業
  • 事業検証・新規技術検証を含む
  • RSCに極力寄せる方針
• 実装
  • スキル診断のステータスAPIの処理時間が画面全体の描画に影響しないように、Suspenseを利用
  • ボタン部分のみ状況によってラベルが変化するためCC
    • ページ全体をRSCで返す
    • ボタン部分のみStreamingで非同期処理
    • サーバー側のAPIコールが完了するまではボタンがLoading状態
    • → 完了後に描画結果が返りボタンが表示される
  • 回答ページ
    • 回答選択のフォーム部分は選択のStateを持つためCC
    • router.refreshを使用することで、再度サーバー側で fetch & renderを実行
      • ただし、同期的な関数なのでサーバ側の処理の完了を待たずに実行される
      • → useTransitionから取れるstartTransitionを使うことで待機する
  • SCを前提にすることでバンドルサイドの削減
  • ロジックを末端に寄せることでSCの領域を広げる
  • DOM,CSSだけで表現できるものを理解することでSCの領域を広げる
  • Router.eventsの廃止
    • URL変更のwatchならusePathname + useSearchParamsで代替可能
    • before unloadなどでページ遷移に割り込んで中断させる方法は見つかっていない