フロントエンド開発における大きなトピックの１つとして「状態管理」がある． 本記事では，昨今の状態管理について，その状況を復習し， また，2019年の自分の開発スタイルについて振り返りながら，あれこれと反省をしたいと思う．
状態管理の選択肢を考えた時，僕がまず思い浮かべるのはreduxだ． 実際，reduxは状態管理のアーキテクチャとして強い人気を誇っていると思う．
AngularではNgRxというreduxを採用した準公式の状態管理ライブラリがある．
Reactでも，Context APIやHooks APIの登場により選択肢が増えたとはいえ， reduxが役割を終えたとは言えないんじゃないかと思っている．
また，最も基本的な状態の持ち方として「コンポーネントローカルな状態」があると思う． AngularやReactだとコンポーネントクラスのフィールドとして状態を持つような書き方になると思う． (SFCでの実現方法には触れないけど，あんまり詳しくないので許してほしい)
自分の開発スタイルとしては，NgRxを導入して開発を進めることが多い． NgRxのライブラリ群で状態管理周りを書いて，コンポーネントからはファサードを通じてアクセスするという流れだ．
また，状態の持ち方として，ストアを積極的に使う方針を取っており， コンポーネントクラスにはあまり状態を置かないようにしている．
ストアに状態を置くことで，以下のようなメリットが得られると考えている．
- 派生した状態を容易に作ることができる
- コンポーネント間で状態を共有できる
- コンポーネントから状態を引き剥がすことで，その役割をシンプルにできる
しかし，このようなスタイルでの開発を振り返ってみて， 上で述べたようなメリットについて深く考えずにストアを乱用した結果， 開発効率と自らの開発者体験を下げてしまっていたのではないか，という反省がある．
例えば，ドロップダウンの開閉のような単純な状態については， 大抵の場合コンポーネントローカルな状態として扱っても問題はないだろう．
こういったケースでストアを使った場合，メリットが得られないどころか， 逆にコードを複雑化させることになるんじゃないだろうか．
状態を再利用したいわけでも，派生した状態を作りたいわけでもなければ， コンポーネントローカルな状態として扱ったところで，さほど複雑さを伴うわけでもないからだ．
僕は，状態の複雑さをきちんと評価した上で，設計上の判断を行うことが出来ていなかったんじゃないか． 自分の中で，コンポーネントローカルな状態について再評価する必要がある気がする．