atomWithAspida
コアの思想
宣言型プログラミングを好まない人には合わないかも
これを利用すると
同じServer Stateのキャッシュを別コンポーネント間で共有できる
Server Stateのモデリングが透過的にできる
APIのレスポンスの形式に縛られない形で宣言的UIにおける6種のステートを絡めてフロントで正規化しやすい
Viewをシンプルにできる
Form Stateの依存データフェッチなどに活用できる
前提知識
多すぎでしょ
どういうときにつかいたいのか
ある程度opinionatedでもいいから、クライアントはユースケースの組み立てに集中したい
Form StateとServer Stateのもつれや依存関係を整理したい
Resource-based Web APIを束ねるレイヤが欲しい
依存データフェッチの依存解決をData-Flow Graphにしたい
そのような文脈で楽して開発したいのワガママに応えつづけた結果の産物
一度出来上がった既存コードとの互換性を維持しつつ改善していったらこうなった
Resource-based WebAPIの問題点をフロントエンドで吸収しているんだなと捉えると良いのかもしれない
必要悪(は言い過ぎか)的な存在
>@koushisa: 複雑SPAの複雑のもとをたどると、根はServer StateとForm Stateの関係性から来ることが多く、この両者の値をRecoilとRHFのintegrationで管理してResolverを組み込むとfield一つ一つを(prevState) ⇒ (nextSchema)という純粋な漸化式(Reducer)として表現できる
お互いが知らない時に、全く同じタイミングで開発されてた
つまりは知らず知らずの内に車輪の再発明のようなことをしていたわけだ
全体最適化の視点でみると、コストを投下してTanStack Queryへ移行すると長期的なメリットが生まれるかも