atomWithAspida
#設計 #宣言的UIのデータフェッチ #宣言的UIの設計レシピ #Server_State #CQS #Atomic_State_Management
https://scrapbox.io/files/63ffd03457e667001c77bef7.png
RecoilとAspidaを組み合わせるユーティリティ
https://github.com/koushisa/recoil-aspida-architecture
https://github.com/koushisa/recoil-aspida-architecture/tree/main/src/features/subject
コード例
コアの思想
Async Selector: APIは「叩く」のではなく「叩かれる」もの
宣言型プログラミングを好まない人には合わないかも
これを利用すると
データアクセスをリソース単位で抽象化したRepositoryのようなインタフェースで操作できる
同じServer Stateのキャッシュを別コンポーネント間で共有できる
Server Stateのモデリングが透過的にできる
モデリングの一例
フロントエンド(SPA)でオニオンアーキテクチャっぽくデータフェッチとドメインを分離する例
APIのレスポンスの形式に縛られない形で宣言的UIにおける6種のステートを絡めてフロントで正規化しやすい
Viewをシンプルにできる
Form Stateの依存データフェッチなどに活用できる
解説記事: https://zenn.dev/link/comments/8045533c079d9b
前提知識
Container/Presenterパターン
Render As You Fetchパターン
データ取得ライブラリを SPA に導入するとなぜ嬉しいのか
コロケーション
宣言的UIにおける6種のステート
複雑GUIにおけるRepositoryパターンの勘所
Resource-based APIとUsecase-based APIの勘所
アプリケーションロジックの命名にCRUDを持ち込まない
開発メモを残したZennのスクラップ
多すぎでしょkoushisa.icon
どういうときにつかいたいのか
GraphQLを使いたいが、バックエンドの実装コストやスキーマの運用コスト的に採用しづらくRESTにしたい場面
勘所: Resource-based APIとUsecase-based APIの勘所やGraphQLとRESTの比較
ある程度opinionatedでもいいから、クライアントはユースケースの組み立てに集中したい
Form StateとServer Stateのもつれや依存関係を整理したい
Resource-based Web APIを束ねるレイヤが欲しい
依存データフェッチの依存解決をData-Flow Graphにしたい
そのような文脈で楽して開発したいkoushisa.iconのワガママに応えつづけた結果の産物
一度出来上がった既存コードとの互換性を維持しつつ改善していったらこうなった
Resource-based WebAPIの問題点をフロントエンドで吸収しているんだなと捉えると良いのかもしれない
必要悪(は言い過ぎか)的な存在
「宣言的UI時代のクライアントサイドDDD大考察」の感想
@koushisa: 複雑SPAの複雑のもとをたどると、根はServer StateとForm Stateの関係性から来ることが多く、この両者の値をRecoilとRHFのintegrationで管理してResolverを組み込むとfield一つ一つを(prevState) ⇒ (nextSchema)という純粋な漸化式(Reducer)として表現できる
jotai-tanstack-query#640916918660300000baf28a
atomWithAspidaを作る過程で知ったのだが、JotaiとTanStack Queryのintegrationととても似ている
お互いが知らない時に、全く同じタイミングで開発されてた
つまりkoushisa.iconは知らず知らずの内に車輪の再発明のようなことをしていたわけだ
全体最適化の視点でみると、コストを投下してTanStack Queryへ移行すると長期的なメリットが生まれるかも
Tanstack QueryとRecoil/Jotaiの連携