Savkin先生の記事を雑にメモする。これらの記事はngrx/storeを使う方法に誘導する感じがあるが、先生がまとめる問題点と解決策を整理してなんとかngrxよりも軽量でAngularにあった状態管理の方法を考えたい動機 (なのでReduxについての記述は飛ばしがち)

Managing State in Angular Applications

複数のバックエンドにあるサーバー、WebWorker、UIコンポーネントが並行して状態を更新するので、状態の管理は難しい。

何をメモリに、URLに保持すべきか？UIコンポーネントがローカルに保持すべきものは？これらの状態を同期するにはどうしたら良いか？

この記事では状態を6つに分類し、一般的な間違いとそれに変わるパターンを紹介する。

Types of State

Server state
Persistent state
URL, router state
Client state
Transient client state
Local UI state

Server state

サーバーで保持される状態。REST APIなどで提供される。

Persistent state

Server stateをクライアントサイドのメモリに保持したもの。Server stateのキャッシュと捉えることができる。実際はより良いUXのために楽観的更新がされる。

Client state

Client stateはサーバーに保存されない。リストをフィルタする設定がいい例になる。リストのアイテム自体はサーバーが保存しているが、それをフィルタする設定はそうではない。

Persistent stateと Client stateの両方をURLに反映するのはいいプラクティス
(It’s a good practice to reflect both the persistent and client state in the URL.) (Persistent stateもURLに反映する？？)

Transient client state

URLには反映されないクライアントに保存される状態がよくある。例えば、Youtubeは再生している時間を保存していて、次に再生するときはそこから再生が始まる。この情報はURLに反映されないので、誰かにそのリンクを送るとその人は最初から動画を再生する。これがTransient client stateとなる。

Local UI state

ボタンの色や、メニューが展開されているかどうかがLocal UI stateにあたる。

状態の種類を決めるときは、それが共有されるかと、ライフタイムについて着目する

State Synchronization

Persistent stateとServer stateはは同じ情報を保持する。Client stateとURLも同様。なのでこれらを同期する必要がある。

...普通の実装をしてSavkin先生がツッコミを入れる図

Mistakes

状態を計算するところとサービスから、状態の管理を分離しなかった
Persistent stateとServer stateを同期する戦略を明確にしていなかった
Client stateとURLを同期する戦略を明確にしていなかった
モデルがmutableだった

Refactoring 1: 状態管理の分離

分離
- サービス
- 状態管理
Redux
- Redux自体がゴールではない
- 非Local stateを1箇所で管理する
- Immutable data

Rule 1: 状態の管理をアプリケーションの残りの部分と分離する
Rule 2: 楽観的更新はエラーに対処するために分離したアクションを必要とする
Rule 3: Persistent stateとClient stateにはImmutable dataを使う
Rule 4: Reduxは目的を達成するためのものであり、それ自体が目的ではない

Refactoring 2: Routerと状態

Router is the source of truth
- Persistent stateとClient stateを管理するが、Client stateは管理しない
- アクションを発行する

Rule 5: 常にRouterをsource of truthとして扱う