Exploring State - LayerX Web Frontend Night イベントレポート

イベント概要

Exploring State - LayerX Web Frontend Night を視聴した。
特に印象に残った内容を以下にまとめる。

• https://layerx.connpass.com/event/348773/

印象に残った内容

状態と共に暮らす：ステートフルへの挑戦

• ステートフルの複雑さは大まかにどちらかになる
  • 状態から別の状態を計算
    • 複雑な関係性は純粋関数に移動してテストする
    • 外界の複雑さは hooks に移動する
    • リアクティブ: 状態間の関係を普通のコードで表現
      • 状態の組み立てができる
  • イベントに応じて状態を変換
    • 状態を変更する関数を純粋関数で表現する
    • 既存の設計 reducer だけでなくアプリに合った設計を選ぶ

React に依存しない状態管理のアプローチ

• 複雑さの分類
  • 非同期のデータ取得起因の複雑さ
  • ビジネスロジック起因の複雑さ
  • パフォーマンス問題
• 今回はロジックが複雑にフォーカス
  • 更新ロジックが複雑
    • UI = f(state)
      • state が決まれば一意の UI が表示される
      • 意図する state が得られれば UI が決まる
      • カスタムフックは React API への依存しており JS 的に純粋ではない
      • useReducer であれば純粋であり良い
  • 参照ロジックが複雑
    • データストアを React から独立させる
    • Jotai などで再レンダーを最小レベルに抑えることができる
      • Jotai は React なしで動作可能で Provider がいらない

複雑なフォームの jotai 設計

• state ではなく他の値・状態から決まる Derived Value にする
  • バリデーション対象は直接の入力値に限らない
• Derived Atom は非同期もそのまま扱える
• ユーザーが直接編集する状態と別の値から決まる値を分ける

更新系と状態

• Suspense 前提だとローカルステートを更新するのは不可
• 差分を state に持つ
  • 画面上のデータとサーバーからとってきた値とローカルで編集した値
• ページネーションした時
  • ローカルで編集した値を初期化する
  • ただページ遷移で 1 つの state 更新を同時にやるのは微妙
  • ローカルで編集した値は今のページのデータに付随する追加データであることを表現するために従属先を覚えておく
    • どの items に従属するか key で表現
  • state の取り回し(上位コンポーネントから下位コンポーネントへ渡す)は state の分割・合成に適した state 管理ライブラリに任せる
    • 例えば Jotai とか

学んだこと

• Jotai は React なしで動作可能
• React19 に更新系の API が来ている
  • useActionState: 非同期処理のアクションの結果を取り扱える。useReducer の非同期版
    • https://zenn.dev/uhyo/books/react-19-new/viewer/useactionstate
  • useOptimistic: 非同期処理成功後の状態を非同期処理が完了する前に UI に反映
    • https://zenn.dev/uhyo/books/react-19-new/viewer/use-optimistic

今後の活用

• 差分を state に持つことでサーバーからとってきた値とローカルで編集した値から画面上のデータを生成するようにするとシンプルになる、複雑な state で実践してみたい
• 下記は完全同意だったので引き続き実施していこうと自信になった
  • 更新ロジックの複雑さは純粋関数に近づけることでテスト容易性を上げる
  • ライブラリ依存を下げる

所感

• Jotai 推し多い
• useReducer が良いはわかるが、パネルディスカッションでは実は多くの箇所では使っていない、switch 文爆発して wrapper 関数書いたりそれ redux-toolkit でよくないかという話が面白かった