composable-architecture

The Composable Architecture（TCA）

TCA は、合成可能なリデューサー、状態の一元管理、副作用の処理を通じて、複雑でテスト可能な機能を構築するためのアーキテクチャを提供します。中核となる原則は、明確な依存関係とテスト可能なエフェクトを備えた、予測可能な状態の変化です。

リファレンスの読み込みガイド

内容が必要になる可能性が少しでもある場合は、必ずリファレンスファイルを読み込んでください。 パターンを見落としたり、間違いを犯したりするより、あらかじめコンテキストを把握しておくほうがよいでしょう。

リファレンス	読み込むタイミング
Reducer Structure	新しいリデューサーの作成、@Reducer、State、Action、@ViewAction の設定
Views - Binding	@Bindable、双方向バインディング、store.send()、.onAppear／.task の使用
Views - Composition	ストアを使った ForEach、子機能へのスコープ設定、オプショナルな子要素の使用
Navigation - Basics	NavigationStack、パスリデューサー、画面のプッシュ／ポップ、プログラムによる閉じる操作の設定
Navigation - Advanced	ディープリンク、再帰的なナビゲーション、NavigationStack とシートの組み合わせ
Shared State	@Shared、.appStorage、.withLock の使用、機能間での状態共有
Dependencies	@DependencyClient の作成、@Dependency の使用、テスト依存関係の設定
Effects	.run、.send、.merge、タイマー、エフェクトのキャンセル、非同期処理の使用
Presentation	@Presents、AlertState、シート、ポップオーバー、Destination パターンの使用
Testing - Fundamentals	テストスイートや makeStore ヘルパーの設定、Equatable の要件の理解
Testing - Patterns	アクション、状態の変化、依存関係、エラー、プレゼンテーションのテスト
Testing - Advanced	TestClock、キーパスのマッチング、exhaustivity = .off、時間ベースのテストの使用
Testing - Utilities	テストデータファクトリー、LockIsolated、ConfirmationDialogState のテスト、@Shared のテスト
Performance	状態更新、高頻度のアクション、メモリ、ストアのスコープ設定の最適化

よくある間違い

1. 機能を細分化しすぎる — 機能を小さなリデューサーに分割しすぎると、状態管理が難しくなり、合成のオーバーヘッドも増えます。実際に再利用する場合を除き、関連する状態とアクションはまとめておきましょう。

2. エフェクトのライフサイクル管理を誤る — 状態の変化に応じてエフェクトをキャンセルしないと、古いデータ、リクエストの重複、競合状態につながります。順次実行するエフェクトには .concatenate を使い、適切な場面で .cancel を使いましょう。

3. ナビゲーション状態を誤った場所に置く — 親ではなく子のリデューサーにナビゲーション状態を置くと、不必要なビューの再読み込みや状態の不整合を招きます。ナビゲーション状態は、ナビゲーション構造を所有する機能に置きましょう。

4. TestStore の網羅性チェックなしでテストする — 「単純な」エフェクトや「明らかな」状態変化に対する TestStore のアサーションを省略すると、バグを見逃します。網羅性チェックを徹底して使いましょう。これにより、リグレッションを早期に発見できます。

5. async/await と Effects を誤って組み合わせる — 適切なキャンセル処理やエラー処理をせずに async/await を .run エフェクトに変換すると、分離保証が失われます。.run 内で yield 文を使い、非同期処理を慎重にラップしましょう。