SwiftUI導入から1年、 SwiftUI導入とVueFluxライクな状態管理

CA.swift 2025/03/03
@アベマタワー10F

Transcript

1. SwiftUI導入から1年、 
 SwiftUI導入とVueFluxライクな状態管理 
 
 2025/03/03 
 
 CA.swift #22 
 〜Swiftの進化を活かした技術基盤への挑戦〜 
 
 CL事業部 吉田 周平 

2. 自己紹介
 2 吉田 周平 (しゅうしゅう)
 
 株式会社 CyberAgent
 Fantech CL 事業部
 24年新卒

3. CLの事業内容 

4. LDHのオリジナル番組や生配信を楽しめる動画配信サービス 
 4
5. SwiftUI導入背景 

6. SwiftUI導入背景 
 6 • SwiftUI導入の理由
 ◦ 新規でジョインするエンジニアがSwiftUI経験者である可能性が高い 
 ◦ コードの可読性とメンテナンス性の向上 
 ◦ Storyboardの差分を見るのが辛い（コードレビュー時の負担が大きい） 
 • 既存のアーキテクチャとの整合性 
 ◦ VueFlux[1]の考え方と大きく異ならないようにする 
 ▪ 単一方向のデータフローを維持 
 ◦ 既存のエンジニアが違和感なく移行できる形にする 
 ◦ アーキテクチャの統一性を確保することで、チーム全体の開発効率を損なわない 
 [1] https://github.com/ra1028/VueFlux
7. VueFluxとは？ 

8. VueFlux [1]とは？
 8 Actions Mutations State Computed View • ReduxやVuexに近い、Swift向けの 単一方向状態管理ライブラリ
 • Ryo Aoyama氏によって開発された 
 • 単一方向データフロー
 Action: 非同期処理やイベントの結果に応じてMutationを発火さ せる
 Mutation: Stateを変更する唯一の仕組み 
 State: 状態をひとまとめに管理
 Computed: Stateから派生値を計算・外部に公開 
 dispatch データの 一元管理 state->ui に派生 [1] https://github.com/ra1028/VueFlux
9. VueFluxをどのように使っているか？ 
 9 ViewController Adapter(Store) State+Mutations DataModel ① User Action ② Call methods ③ Action dispatch ④ Update ViewController ⑤ 変化を購読→更新 ③ Action発行 ② Call methods
10. VueFluxをどのように使っているか？ 
 10 ViewController Adapter(Store) State+Mutations DataModel ① User Action ② Call methods ③ Action dispatch ④ Update ViewController ⑤ 変化を購読→更新 ③ 発行されるActionの定義 ④ 状態の更新
11. VueFluxをどのように使っているか？ 
 11 ViewController Adapter(Store) State+Mutations DataModel ① User Action ② Call methods ③ Action dispatch ④ Update ViewController ⑤ 変化を購読→更新 ⑤ 変化を購読→更新
12. VueFluxライクな状態管理 

13. SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 13 ViewController Adapter(Store) State+Mutations ViewController UIKit + VueFlux Call methods Action dispatch Notify Change ViewControllerが 変更を受け取り、UI を作り替える SwiftUI View ObservableObject @Published State SwiftUI View SwiftUI + VueFluxライク Call methods Action dispatch Notify Change 状態変化を検知 →自動で再描画 Adapter State
14. SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 14 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change Screen(親View) • @StateObject var adapter • dataModelをContentに渡す ↓ クロージャーでイベントを渡す Content(子View) • UIの実装のみ • 子→親で状態を返さず、 あくまで"イベント"送信
15. SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 15 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change Screen(親View) • @StateObject var adapter • dataModelをContentに渡す ↓ クロージャーでイベントを渡す Content(子View) • UIの実装のみ • 子→親で状態を返さず、 あくまで"イベント"送信
16. SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 16 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change • Store機能 ◦ @Published var state • 非同期処理やイベントの結果 に応じてActionを発行する
17. SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 17 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change AdapterからActionを受け取り mutateで状態を更新
18. 導入したメリットとデメリット 
 18 メリット デメリット • ボイラープレートが増える 
 ◦ シンプルな機能でも雛形のコードが必要 
 • 大型機能ではAdapterが肥大化しやすい 
 ◦ 非同期処理や画面遷移など外部とのやり取 りを全てAdapterで行うため 
 • 画面数が多いとコード量が増える 
 ◦ Screen, Content, Adapter, State, DataModel←最低でもこの５つが必要になる 
 • SwiftUIの恩恵を受けられる 
 ◦ 宣言的UIとなり、UIKit+VueFluxよりもコード がシンプル
 ◦ Storyboardを使う必要がなくなり、コードレ ビューしやすい
 • テストがしやすい
 • ライブラリの依存が少ない 
 

19. まとめ
 19 1. SwiftUI導入の背景
 a. 新規エンジニアがSwiftUIを学んでいる可能性が高い 
 b. Storyboardの差分確認が辛く、宣言的UIを検討 
 c. 既存のVueFlux（単方向データフロー）と大きく矛盾しないアーキテクチャが必要 
 2. VueFluxをどのように使っているか？ 
 a. 単方向データフロー: Action → Mutation → State → View(Controller) 
 b. Adapter(Store) + State + DataModelを組み合わせ、ViewControllerがUI更新 
 3. SwiftUIでVueFluxライクな状態管理を実現 
 a. Screen & Content の構成: Screenが親Viewとして@StateObjectを保持し、ContentはUI表 示とイベント通知に特化 
 b. Adapter(Store)はObservableObjectとして@Published var stateを管理し、mutating func mutateで単方向フローを再現 

20. テスト
 20 • Adapterから受け取るAPI通信のAPIから、正しい状 態更新ができているかテストすることができる 
 • Actionのassociated valueにレスポンスを入れて Stateで変換する
 
 

21. Stateからの実行を行う「command」機能 
 21 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change Command Stateが変わった瞬間にUI イベントやログ送信が可能