設計実装のみならず技術浸透のための取り組みも含めて解像度高く紹介されており、どのプレゼンも非常に濃い内容だった。ひとつめのTCAに関するプレゼンは、すでに自社プロダクトにTCAを導入している身としては復習要素もありつつ、Reducerの採用／非採用について感覚的だった部分が言語化されていたため、学びになった。
イベントページ：https://cyberagent.connpass.com/event/342952/
The Composable Architecture (TCA) を用いたAmebaのリアーキテクチャ
@devdazy さん
- 従来：MVVM + RxSwift、VMは状態持たずデータを流すハブだけ
- 課題：ロジックの複雑さ。モデル肥大化、可読性低下、保守性拡張性の低下とともに開発速度が低下
- VM が状態を保持せず SwiftUI と相性悪い、RxSwift 依存が Concurrency と相性悪
- TCA の概要
- メリット・デメリット
- Good：ロジックが明確になり、見通しが良くなる
- すべてのイベントが列挙される。非同期処理のEffectで状態更新できないため、成功失敗を網羅的に書かざるを得ない
- テストの網羅生にもつながる
- e.g. 読み込みだけでなく、読み込み完了後の処理もテスト書かなければ失敗する
- Good：画面遷移をシームレスに移行できる
- SwiftUI → UIViewControllerへの遷移
- TCA x UIKitでは、ほとんど SwiftUI と同じインターフェイスで実現できる
- Good：ロジック分割が簡単にできる
- ロジックである Reducer を別の Reducer に分割・合成したりできる
- Action / State は親からも観測できる
- Bad：学習コストが高い
- フレームワーク丸々ひとつに対する理解が必要
- TCA独自の記法
- 例を作り、マイグレーションドキュメントを作り、テンプレ機能を活用する
- Bad：パフォーマンスが最良ではない
- Reducer を分割しやすい反面、不要な View にも Reducerをつけがち。（Action送る処理は負荷が高い）
- Action を極力減らすよう吟味が必要
- View 側での処理完結も選択肢に
- Bad：Point Freeに依存
- RxSwiftの例に同じ
- 記法のブレがかなり抑制されるのは Good
- Good：ロジックが明確になり、見通しが良くなる
Q&A
- 分割粒度について：画面の量にもよるが、スクロールしない画面では基本的に1画面 1 Reducer だが、セクション持つような単位ではセクションごとに分割する
- ロジック持たない限りは Reducer 持たせない（ボタン置いてあるだけとか）、通信して自身を更新するばあいは Reducer を持たせる
SwiftUI導入から1年、SwiftUI導入とVueFluxライクな状態管理
@TyrionJP さん
“聴講メモ：CA.swift #22 〜Swiftの進化を活かした技術基盤への挑戦〜” の続きを読む