RecoilでWrite系処理の設計パターンを考える

もうWrite系処理はZustandでよくない？

以下のスクラップにも書いたようにRead系とWrite系は本質的に関心事は異なっている。
https://zenn.dev/link/comments/d2b4b80841c162

Redux, ZustandのようなFluxインスパイア系なライブラリはGET系のリクエストも更新系で扱う。
これは思想の問題であり、善し悪しで図れるものではないところ。
どちらかというと利用者が受け入れるか受け入れないかの問題。

ただしReact Concurrentのセマンティックと衝突するというのは認識しておいたほうがいいかもしれない。^[1]

https://scrapbox.io/fsubal/Redux「GET_リクエストは更新系」

RecoilのSelectorはRead系にもなれるし、Write系にもなれる。
どのように扱うかは利用者に委ねられているため、Recoilのデータ設計においてはSelectorをどの抽象度で扱うかというのがキーとなる。

一度立ち返ってRead系とWrite系の関心事を整理する。

以下で想定しているアプリケーション規模は https://zenn.dev/link/comments/238de1fb4a497d に記載している
そもそもフロントエンドにこのような複雑さを持ち込まないのが理想的という前提はあるが、^[2]
止むにやまれない事情はあるため、フロントエンドに閉じた形での考え方として提示しておく。

Read系

• 処理をUIと近い位置に配置するコロケーションスタイルが適している
• UIごとに再利用性の低い整形ロジックが必要となる
  • 具体的なロジックは子に置くため分散傾向にある
• 冪等性が重要
• 非同期処理がメインなので初期化時の遅延評価が可能な点とSuspenceに対応していると柔軟性が高まる
  • Render As Fetchパターン
• リクエストがウォーターフォールとならないようにするためにキャッシュ先読みや並列リクエストが可能とする
  • リクエストの詳細は自身で持ちつつも発火は外部から制御することで設計とパフォーマンスを両立させる

Write系

• UIとは少し離れた位置でロジックを管理する
  • 機能単位のルートでストアを作ったりする
  • Reduxの場合はアプリケーション全体でストアを持つ
    • RTKのSliceであれば擬似的に機能単位でストアを持てる
• 副作用が主
  • 強整合性が求められる
  • Read系にデータが更新されたことを伝える手段が必要
• 複雑性が高い
  • サービス固有のドメイン知識が必要
  • 複雑性のしきい値を超えてきたらValue Object, Domain Modelのようなモデリングを駆使するケースがある^[3]
    • モデリングのモチベーション
      • 全体の処理フローを追いやすくする
      • テスタビリティの向上
        • 純粋関数の割合を増やす
        • モック可能にする
      • ドメイン抽象
        • Union Distribution, Structural Subtypingによるドメイン抽象
        • 永続化層(フェッチ)、ドメイン層(モデリング)、アプリケーション層(制御)を分離する事によるコードベースの言語化＆構造化

 // 予約メニューを選ぶみたいな想定
 
 ---
 // 永続化層
 
 type MenusEntity = {
   value: Menu[]
   hasMenu: boolean
   hasMultiple: boolean
   hasContents: boolean
   head: Menu | undefined
   defaultMenu: Menu | undefined
 }
 
  // APIレスポンスを基にエンティティを作成する純粋関数。これはテストする。
  const createMenusEntity = (menus: Menu[]): MenusEntity => {
    /*~*/
  }
 
 // データフェッチを行ってエンティティを返す
 // Repositoryパターンと同義
 export const menusEntity = selector<MenusEntity>({
   key: 'menusEntity',
   get:
     async ({ get }) =>
       const menus = await fetchMenus()
       return createMenusEntity(menus)
     },
 })
 
 ---
 
 // ドメイン層
 // サービス固有のドメイン層
 // エンティティの状態<->ドメインの状態をマッピングする
 // ユビキタス言語が使えたら◎だが、言語補完的な意味合いも強い
 // エンティティの状態を特定の課題解決のために抽象化したもので、これがアプリの状態制御の核となる
 // 例ではタグで区別できるようにした
 // タグにより後述のアプリケーション層でドメインモデルの状態によるポリモーフィックを実現できる
 
 type MenusDomainModel =
   | {
       type: 'blank'
     }
   | {
       type: 'single'
       menu: Menu
     }
   | {
       type: 'multiple'
       menus: Menu[]
     }
   | {
       type: 'skippable'
       defautMenu: Menu
     }
 
 // エンティティを受け取り、ドメインモデルを返す純粋関数。これはテストする。
 const createMenusDomainModel = (menusEntity: MenusEntity): MenusDomainModel => {
    const {
     value: menus,
     head,
     hasMenu,
     hasMultiple,
     hasContents,
     defaultMenu,
    } = menusEntity
    
    if (!hasMenu && !hasContents) {
      return {
        type: 'blank',
      }
    }
 
     if (defaultMenu !== undefined) {
       return {
         type: 'skippable',
         defaultMenu,
       }
     }
 
    if (!hasMultiple) {
      return {
        type: 'single',
        menu: head,
      }
    }
 
    return {
      type: 'multiple',
      menus,
   }
 }
 
 // 永続化層のエンティティがSelectorで抽象化されていることでキャッシュが効く
 // エンティティのユースケースごとに複数のドメイン層を派生させることも簡単
 // 規模によっては`menusEntity`, `createMenusEntity`と統合してしまっても良い
 export const menusDomainModel = selector<MenusDomainModel>({
   key: 'menusDomainModel',
   get({ get }) {
     return createMenusDomainModel(get(menusEntity))
   },
 })
 
 ---
 // コンポーネント

 // 該当コンポーネント専用のPresentationModel
 const presentationModel = selector({
  key: "menusPresentationModel",
  get: ({get}) => {
    // ドメインモデル
    const menus = get(menusDomainModel)
    // ビジネスロジック    
    return someBusinessLogic(menus)
  }
 })

 // ドメインモデルを受け取り、特定のユースケースを達成するビジネスロジック
 // ユースケースに依存するのでViewの関心も含んでよい(むしろViewと同じファイルに配置するのがオススメ)
 // I/Oが分離されてるのでビジネスロジックを純粋関数化しやすい、テスタビリティが高い
 const someBusinessLogic = (menus: MenusDomainModel) => {
   switch(menus.type) {
    /*~*/
   }
   return /*~*/
 }
 
  
 const Menus = () => {
   // 対象のデータ取得とビジネスロジックをコンポーネントから分離できた
   const menus = useRecoilValue(presentationModel)
   
   return <>/*~*/</>
 }

Recoilはどうなのか

これを踏まえてみたときに、RecoilはRead系への解決策を示している。

• データフローグラフ
• 遅延評価
• Suspence
• Loadable
• Concurrent

上記のドメイン抽象のキモは永続化層とアプリケーション層が切り離されていることで、それによってアプリの制御構造と依存関係が分離される。

宣言的プログラミングにおいてはリソースの依存関係こそがドメインの本質であり、オーバーフェッチを気にすることなく永続化層(menusEntity)から派生するSelectorをいくらでも作ることができる。
また、データフローグラフでは参照時に依存ノードが全て同期的に評価されるため、フェッチが終わっていないことを気にする必要もない。

つまりユースケースごとに時と場所を選ばずドメイン抽象が可能なのでスケールするということ。
一般的なアプリであればこれだけでも十分に価値がある。

また、Loadableによってエラーハンドリングをコンポーネント側まで遅延させられるので全体的なロジックをピュアに保つことができる。

ドメイン層(menusDomainModel)が独立しているのでRead系、Write系でも実装を使い回すことができる点も魅力的。

• Read系ではコンポーネントのローカルスコープでselectorを作って整形処理を挟むことができる
  • stateの形を考える際、「表示にとって都合のいい形」を考えなくていい
  • 子に表示のためのロジックを寄せることが出来る
  • 宣言と利用が近くなる、オンデマンドにServerStateを取ってこれるしキャッシュが効く
• Write系ではAction内のドメインロジックをselectorに移譲してロジックをシンプルに保てる
  • 本質的なロジックの見通しがよくなる
  • Actionが肥大化することを防ぐ

このような抽象化はFluxインスパイア系の状態管理では難しく、ここ数年Recoilを使っていて感じたパラダイムシフトだと考えている。

Read系とWrite系の技術スタックを分けるという考え方

少し話が広がるがCQRSでアーキテクチャを組む場合、Read系にWrite系で技術スタックを分けるといった考え方があるらしい。

これは上述のように関心が異なり、Read系は柔軟さ、Write系は厳密さが求められるからだと思う。^[4]

この考え方を借りれば

• Read系: Recoil(Jotai)
• Write系: Zustand

という考え方もあながち間違っていないのかもしれない。
RecoilとZustandをつなぐやり方を考えてみる。

https://zenn.dev/koushisa/articles/1d5272454576e1#モジュール化する

上記を書きながらRecoilのWrite系処理の設計はどうあればよいかと思ったのを考える

似た話がGitHubのissueに残っていたが、Recoilはあくまでもシンプルさを重視することから公式としてAction/Reducerパターンを入れることは考えていない様子
https://github.com/facebookexperimental/Recoil/issues/571

「自分たちの要件に合わせて抽象化してくれ、そのために合成しやすいシンプルな基盤用意しとくから」的なRecoilの思想を感じた。

なので、自分の文脈でほしくなった設計パターンを考える。

• やりたいこと
  • atomの更新ロジックを列挙できる
  • atomを非同期に更新できる
  • Recoilのロジック層とコンポーネントのビュー層を分離できる
  • 全て型がつく
  • 薄くつくる

手始めに、概要の記事で作ったatomCallbackを手直ししてサンドボックスを作った

https://codesandbox.io/s/upbeat-lichterman-1t5s6j?file=/src/Counter/Counter.state.ts

この時点でやりたいことは全て実現出来ている

counter: numberのようなプリミティブな値であればこれで十分だということがわかった。

ただし、リアルワールドにおいてはオブジェクトにしたいこともあるし、オブジェクトの特定プロパティの変更だけを監視できることも求められる。

代表的なものとして、Reduxはメモ化を駆使してオブジェクトのデータでもパフォーマンスを損なわずに扱えるようになっている。

次はatomをオブジェクトにして更新と参照を分離できないかを考える。

話はそれるが、React 18で追加されたuseSyncExternalStoreを利用すればシングルトンのオブジェクトで独自の状態管理を作る事は可能

参考:
https://zenn.dev/hatchinee/articles/c075fdef8f54d0

JotaiはatomWithReducerのユーティリティが公式で提供されている。
でも非同期処理は対応していないっぽい？

単純に更新と参照を分離したいだけならuseSyncExternalStoreでもいい。
Recoilの強みは

• データフローグラフ
  • データの宣言、ソース、ロジックの分離
  • キャッシュ管理をプレゼンテーション層から分離する
  • 遅延評価可能
• Suspenceで非同期処理を同期的に扱えること。

この特性を活かしつつ、以下の要件で考えることにする

• 初期値を非同期 & 宣言的にセットできるようにする
  • データフローグラフの仕組みにのっかって参照時に初期化される & Suspendする
• 厳密な純粋性にはこだわらない、更新が分離されて関数でできればヨシとする
  • 更新は非同期可能
• 参照はプロパティ単位で監視可能
• コールバックの中で現在値を取得可能
  • react-hook-formでいうgetValues
  • https://react-hook-form.com/api/useform/getvalues

const {
  // フックで更新、参照を提供する
  state: [fooState, useFoo, useFooActions],
  FooProvider,
} = atomWithAction({
  // 初期値
  initialState({ get }) {
    return {
      // 他のデータフローグラフから非同期に初期化出来る
      bar: get(barState),
      baz: 'baz',
      count: 0,
    }
  },

  // アクション
  // (cb: RecoilCallbackInterface) => (arg: ${Arg}) => ${Return}
  actions: {
    reset: (cb) => () => {
      cb.reset(fooState)
    },

    incrementAsync:
      ({ set }) =>
      async () => {
        await sleep(1000)

        set(fooState('counter'), (prev) => prev + 1)
      },

    updateCount:
      ({ set }) =>
      // ValOrUpdater<number>は ((prevState) => newState) | newState
      (valOrUpdater: ValOrUpdater<number>) => {
        set(fooState('counter'), valOrUpdater)
      },
  },
})

const FooWrapper = () => {
  return (
    // アンマウント時に状態をリセットする
    <FooProvider>
      <Component />
    </FooProvider>
  )
}

const Component = () => {
  const { getValues } = useFoo()
  const actions = useFooActions()

  const handleReset = () => {
    const currentCount = getValues('count')

    alert(`現在のcountの値: ${currentCount}`)

    actions.reset()
  }

  return (
    <>
      <button onClick={handleReset}>reset</button>
      <br />
      <Counter />
    </>
  )
}

const Counter = () => {
  const { watch } = useFoo()
  const actions = useForActions()

  // countの値の変更を監視
  const watchedCount = watch('count')

  return (
    <>
      <p>{watchedCount}</p>
      <button onClick={() => actions.updateCount(3)}>updateCount</button>
    </>
  )
}

命名は暫定でReact Hook Formからひっぱってきたがフォームとしてのユースケースは考えない（バリデーションなどが入ると複雑化するので）

上述の擬似コードはまだしっくりきていないので場合によってはこれRecoilじゃなくてもよくない？といった結論もあり得るな。
この辺は作りながら考える。

ReactのステートとRecoilのステートの重複管理は避けたいので基本的にデータの実態はRecoilに置く前提で、今回はスコープを絞ってオブジェクトのatomをいい感じにReducerっぽく扱うことを目標にする。
atomをオブジェクトで持てるとロジックが凝集されるので管理しやすいはず。

先駆者であるReduxが流行ったのには何か理由があるはず。

設計上のReduxの利点を振り返る。
そこから逆算的に必要なもの、足りないものを把握して道筋を整えていく。

https://speakerdeck.com/takefumiyoshii/redux-falseli-dian-wozhen-rifan-ru?slide=32

• ActionとReducerが多対多になっている
• DispatcherがActionを抽象化してコンポーネントとロジックを疎結合にする
• Actionを購読するReducerは関心事に分割することで高凝集に出来る
  • 実質action.typeのswitchを行うだけの関数なのでいくらでも分割出来る
  • Reducerがステートマシンの役割になっている
  • ReducerはActorとも言えるか
• Dispatch→Action→Reducerの流れと役割を厳しい制約で縛ることで副作用を起こす層が限定的になること
  • 片手間フロントエンドの人でもデータフローを1から勉強する必要がない
    • ので設計として破綻しづらい
  • ここには反対意見もある
    • 学習コストがかかる
    • コード量が多くて直感的ではない

イベント駆動なデータフローとなっているため事実上いくらでもスケールするというのはReduxならではの利点。

ただ、最近はDispatchとActionをイベントで抽象化することのメリットを考えた時に、疎結合であることのメリットよりも保守のしづらさ、というデメリットが上回る場面も多いなとも思う。

// Redux
const dispatch = useDispatch()
const handleChange = () => {
  dispatch({
    type: "HOGE_CLICKED",
    payload: {
      foo: "bar"
    }
  })
}

// RTK
const dispatch = useDispatch()
const handleChange = () => {
  dispatch(updateHoge({ foo: "bar" }))
}

// Hooks
const updateHoge = useUpdateHoge()
const handleChange = () => {
  updateHoge({ foo: "bar" }))
}

また、Reduxは非同期処理に弱いという欠点がある。
状態遷移の純粋性が重要なので非同期処理はmiddlewareを介する必要がある。

ここが設計上での悩みどころで、ActionやReducerに本来凝集されるべき処理が分散してしまったりなど扱いが難しい。コンポーネントと離れた位置でロジックを管理するため、1つ改修に対してファイルを跨いで複数箇所を治す必要があったりなど、影響範囲が広くならないように気をつける必要がある。
型アノテーションが頻出するのも地味に大変。

RTK Queryもあるが、なんというかtoo much感とDSLが強すぎてというか1年後見た時に「どうやって動いてるのかわからん」みたいな事態になりそうでイマイチ手を出しづらい。
というのとServerStateはアプリケーション全体で共有したいわけではなくて特定機能（またコンポーネント）のスコープで管理したい。SSoTのReduxとは相性が悪い気もする。
食わず嫌いはよくないので後から試す。
OpenApiからデータフェッチのhooksを生成できるのは便利ではある、でもReduxじゃなくてもよくない？

本チケットはRecoilでReducerを作るのがゴールだが、その先の最終的な目的地は、

• 捨てやすく、スケーラブルなデータフロー
• Reduxから学び、スケールさせるべき箇所とそうでない箇所の見極めを付ける
• 自分達のドメインに適したアーキテクチャを作らねばならないときの勘所を養う

話がReduxに脱線してしまったがここまでのまとめ

本チケットのゴール

• Recoilでオブジェクトのデータに対する更新と参照が分離されたReducerっぽいパターンを考える
• 厳密な純粋性にはこだわらず、Actionで非同期処理/状態遷移を行えるようにする
  • Action/Reducerで分離は可能だが、強制はしない ^[1][2]
• イベント駆動にはしない

• 試しに実装する
  • 画面要件は後段で考える

チケットクローズ後に考えていきたいこと

• イベント駆動が適した要件の整理
• スケールを前提としたときの勘所
• 処理フローに制約をもたせる
  • 非同期処理を扱う箇所
  • ステートを更新する箇所
  • テストする箇所

やっぱRecoilじゃなくてもよくない感が強いな。
ReduxをシンプルにしたいだけならZustandで十分な気がする。

https://github.com/pmndrs/zustand

小さく、速く、スケーラブル
フックに基づいた快適なAPIを持ち、boilerplateyでもなく、意見も言いません。
ゾンビチャイルド問題、reactの並行処理、混合レンダラー間のコンテキストロスなど、よくある落とし穴に対処するために多くの時間が費やされています。

ドキュメント見た感じすでに自分がWrite系処理で欲しかった物が全部入ってる。(middleware系とか)
それなのにバンドルサイズ1.16kb??神か。

もうWrite系処理はZustandでよくない？

JotaiはZustandのintegrationがすでにある。

https://jotai.org/docs/integrations/zustand

次はRecoilを使う理由がなくなってきたぞ。