iOSアプリ開発チームに所属しているcoffmarkです。iOSチームではSwiftUIを使って開発を進めています。導入するまでの道のりについて)で説明しています。SwiftUI導入を進めていく中で、導入後に改善した点がいくつかあります。今回はその中でもViewState列挙体を使ったSwiftUIの状態管理についてお話しします。iOSアプリチームでは以下のような構成でiOSアプリを開発しています。詳細はブログ記事(iOSチームではリファレンスレポジトリを運用しています)をご覧ください。大まかな概要としては下記の通りのプロジェクト構成・SwiftUI実装方針です。プロジェクト構成RxSwiftを使ったkickstarter/oss-iosを参考にしたMVVMアーキテクチャの構成です。準拠したDataSourceクラスを実装しています。画面遷移やアラートはUIKitを使って出し分けています。今回は架空の設定画面(SettingView)を取り上げます。以前はDataSourceクラスメンバを参照し、Viewを出し分けていました。修正後は画面の状態を管理するViewState列挙体で画面の状態を管理するように修正し、実装の見通しが良くなりました。画面によってViewState列挙体は異なりますが、SettingViewでは以下のような列挙体を定義しています。Bool)}得られた知見をSwiftUI.View及びViewModelの実装を踏まえつつ、お話しします。修正前のコードでは、DataSourceクラスに画面の表示要素や各フラグ実装していました。画面の不整合が起きないことを担保するために、テストコードで全てのDataSourceクラスメンバの挙動を確認する必要がありました。複数のフラグで画面を出し分けているので、可読性も良くありません。}}ViewModelの実装では、DataSourceクラスメンバを全てDriver変換し外部に公開しています。前述した通りDataSourceクラスメンバをSwiftUI.Viewは参照しているので、各DataSourceクラスメンバを更新するたびにSwiftUI.Viewも更新されてしまいます。他のDataSourceクラスメンバも同様にDriver変換して外部に公開しています。画面の状態管理をViewState列挙体で行うことで、簡潔に実装できました。Driver変換します。Viewの更新回数と一致するため、Viewの更新回数を意識してテストを書くことができるようになりました。補足として1画面に対して1つのViewState列挙体で管理するのが難しい場面もあります。その場合では子ViewごとにViewState列挙体を実装しています。関数を多用し過ぎている点が課題として挙げられます。多くの場合実装時に気づくことができますが、意図せずViewState列挙体を書き換える実装ミスが発生することがあります。Concurrencyを用いて簡潔に実装できないかを現在チームで検討している途中です。Concurrencyの導入に向けて検討を進めていこうと考えています。2024に参加しています。hiring!株式会社ドワンゴの教育事業では、一緒に未来の当たり前の教育をつくるメンバーを募集しています。カジュアル面談も行っています。お気軽にご連絡ください!カジュアル面談応募フォームはこちらpitta.mewww.nnn.ed.nico開発チームの取り組み、教育事業の今後については、他の記事や採用資料をご覧ください。speakerdeck.comSwiftUIの標準Listを用いた実装でパフォーマンス上の懸念が発生しました。List編SwiftUIの導入を行いました。(3)引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。