技術とかの雑なToday I Learnedメモ

状態管理のライブラリをどうするかの記事を読んだ

状態管理 ベストプラクティス 2021 is 何

最近 Vue というか Nuxt で Composition API を利用して状態を持ちそれを hooks/usecases という形でリアクティブに変更・ビューに反映するというような書き方をしている。

が、global/local に関わらず状態が hooks/usecases 層に散乱(この表現は語弊があるかも)しており、たぶんこのままでもうまい解決方法はあるんだと思うけど、他のプロダクトはどうしているのかな〜と思ってググった。

JS 状態管理ライブラリ探索記 - Introduction - to-R Media

状態管理に関しては Flux/Redux/Vuex が大半だった時代から自分の知識がアップデートされてなかったので、最近話題になっていた Recoil とか Jotai がどういうものかよく分かってないし、なんならこの記事のライブラリの図にある半分くらいは所見のものだった。

状態管理ライブラリの特性を、Single or Multi と Direct or Indirect に分けて、各ライブラリがどこに当てはまるのかを示してくれていて、めちゃくちゃわかりやすい。

Single or Multi

Single or Multi は、ストアが一つか複数かの違い。

個人的に Redux や Vuex を書いていたので Single のほうが馴染みが深い、が Redux を使っていたとしても hooks でコンポーネントに local な state を持たせたりもしていた。コンポーネントに local な state はそのコンポーネントがアンマウントされれば破棄されると思う(めちゃくちゃ曖昧なのでこの表現や処理が間違ってたらごめんなさい)ので、いわゆる「永続的な(この表現もちょっと微妙な気がする)状態」を管理するという意味では Store という一つの場所に状態が詰め込まれている。

Multi はどういう感じなんだろう。ちょうど今自分が使っている Composition API を使った状態管理は Multi っぽい。

グローバルな空間に定義された変数という意味では一緒だけど、それを中央集権的に管理するのではなく、hooks/usecases ごとに管理しているので Multi っぽさはある。

個人的には Single のほうがわかりやすい気もするけど、実際のところどうなのかは分からない。どのみちスコープがコンポーネントに閉じた local な state は確実に必要になってくる気がする。

Direct or Indirect

これは state を直接いじれるかどうかだけど、個人的には Indirect 一択かな〜という気もする。

よほど規模が大きくならないことが確定しているアプリケーションでないと、Direct に state を変更すろのは複雑化するイメージがとても強い。イメージだけど。

関数を呼ぶことでしかそのモジュールの変数を変更できない(private のアクセス修飾子と同等?)ようにするほうがいいかなと思っているし、簡単さを失うとは書いてあるものの慣れればむしろこちらのほうが分かりやすい気がする。気がするだけだけど。

まとめ

ちょっと思ったより何も分からなかったのでもっと記事漁ってみようと思う。

あとこの to-R の記事の続きがまだ公開されていないようなので、次の Redux 編が楽しみ。