を馬鹿なりに考えて見た。
きっかけ
業務外で他人のFlutterによるBLoC + Providerの構成でのFirebase認証処理を見ることがあったのですが、それは私が学習初期に参考にしたGithub上に転がっていた実装と比較して、悪い実装に見えました。
しかし、完成優先で仕事で行っているわけでもなかったので、指摘をせずにスルーしてたのですが、内容整理をしたかったのでQiitaに起こしました。
間違っていると考える実装
- 画面からVMを通じてサーバに認証をリクエストする。
- 認証結果を画面で受け取り、結果を判定。成功の場合は次のTOP画面へ。
なぜ違うと考えたか？
- 画面にロジックを持たせることになるため。
- 認証状態はアプリの状態として持ち回るべきであり、これを行わない場合VMごとに認証レポジトリを呼び出す必要がある。
- Firebaseは認証状態変更リスナーがあるので、リアルタイムに認証状態の変更をすることができる。使わない手はない。
- 認証結果による次のアクションを認証サーバーではなく、画面が判断しており役割分担に誤りがあると考えた。
他にも様々あると思いますが、コーディングの観点で思いつくものを書きました。
正しいと考えている実装
認証の状態を保持した上でトップに描画のコントローラ（状態に応じて返す画面をswitch文で返すビュー）をおき、認証状態に応じて画面を切り替える。
Firebaseの場合はログイン画面モデルが認証結果を受け取る必要ななく、認証状態プロバイダーの中でFireStoreのインスタンスに認証状態変更リスナーを利用しさらに楽に実装できる。
まとめ
フロントエンドにおけるビュー層のあるべき姿は、あくまでコントローラが指定した状態をそのまま投影べきだと考えます。
サインインのスコープは短絡的にはサインイン画面に対するものに見えますが、アプリ全体の状態なので認証状態を保持するプロバイダーによって判断すべきだと考えます。