状態管理の実装の問題について about milktea HOT 11 CLOSED

案2はアカウントが切り替わるごとにストアを切り替える必要があり、またストアごとにイベントを取り扱うようなケースでは一度サブスクライブを解除する必要があるので不便と考えられる。

from milktea.

Idとしては案1が相応しいと考える。
またこのケースで実装する場合、候補キーとして扱えるIdオブジェクトを作成しIdの実装方法に依存しないようにすることが最適だと考えられる。

from milktea.

考えられる具体的な方法

1. Entityを持つLiveDataを持たせたStateパターンで管理し集約単位で管理するようにする。
2. Storeで集中的に管理し変更などのイベントをFlowなどでViewModelへ伝えViewへ更新イベントを伝播させる
3. Reduxパターンを導入する

いずれもStoreなどを用いて集中的に管理していることには変わりがない。
また更新イベントの伝播方法に違いがあるがあまり違いはないがViewModelへの実装が大きく変わってしまう。

from milktea.

１はViewModelの実装が複雑になることが予想される
２はLiveDataに完全に依存しており、LiveData特有の挙動がデメリットにもデメリットにも転じる可能性がある。
３は変更量的に無理がある可能性がある。

from milktea.

• User
• Note
• File
• Poll
  以上を集約とする

from milktea.

LiveDataを使用する場合どの部分にLiveDataを利用するのか?
State部分
NoteならReactionなど

from milktea.

削除状態も管理するのならStateなどでNoteをラップするのが好ましいか?

from milktea.

現状得た結論
Entityには状態は持たせない。
またModel間の依存が考えられるためEntityごとにFlowやObservableをもたせるよりDispatcherなどでイベントを流すほうが好ましいと考えられる。
理由として、RecyclerView.Adapterでobserveするのはリソース開放のタイミングが非常に複雑になりややこしくなることが考えられる。

from milktea.

今後以下のような責務をもたせたい
Model 状態を持ち変更や削除などのイベントを発行する
ViewModel Modelから得た情報をViewが扱いやすい形に変換する。また変換する

from milktea.

Idについての問題
現状リモートと同じIdを使用しているが以下の問題が発生した。

• Noteはアカウントやインスタンスごとにより状態が異なるため識別する必要がある。
• リモートのIdはインスタンス内では一意であるがアプリ内では複数インスタンスが混在するため一意ではない。

解決策

• 案1:アカウントIdとリモートのIdを組み合わせた複合Id
• 案2:従属するアカウントやインスタンスごとにストアを切り分ける

from milktea.

これによりアカウントごとにストアを管理することもなくまた利用者はアカウントを意識しなくて良くなった

from milktea.