> プレゼンテーションロジックとレンダリングロジックを分離する用途であればカスタムフックだけでも十分。最初はuseStateでミニマムに作りつつ、ステートが増えてくる中でメモ化, 再レンダリングの局所化, 状態の依存関係とレンダリングの一貫性を維持するのが難しいときにはじめて検討すると良さそう。

>そして、本質的にステートフルなGUIを作るのは難しい。問題解決の手段としては、要件の取捨選択の一つとしてあえてGUIのステートフルさを抑えるようにして「技術の損益分岐点」を見極めるという考え方もある。

>

>なんというか、問題解決が目的であれば、Atomic State Managementを導入する前にやるべきことがあるという話。

> 既存ライブラリ(ReduxやRx)の勘所や正規化, SSoT, Lifting State upなどの基礎概念を知らずになんでもかんでもAtomやAsync Selectorにするとただの無秩序グローバルステートの集合体となってしまい、複雑で難解なコードベースになってしまう。

> 「ロジックやデータをRecoil/Jotaiに寄せる」というのはある程度状態管理に関するメンタルモデルが出来上がったタイミングで検討するといいだろう。

> チームで開発する場合、AtomやSelectorの粒度は人によってブレがちなためそこを牽引できるような人がいると良い。

>

> React docs を読み込んでからある程度「宣言型プログラミング」について語れる状態だと丁度いいのかもしれない。