android-compose-state-effects

Android Compose の状態とエフェクト

使用するタイミング

• リクエストが次の内容に関する場合に、このスキルを使用します：Compose の副作用に関する問題、remember と derivedStateOf の使い分け、Compose 画面での Flow の収集。
• 主な目的：リークやループを発生させずに、Compose の状態、remember API、副作用、スナップショット、ライフサイクルを考慮した収集を管理します。
• 問題がコンポーザブルや Compose ランタイムのプリミティブ内にある場合に、このスキルを使用します。アプリ全体の状態保持オブジェクトやリデューサーを再設計する場合には使用しません。
• このスキルは Compose 内のランタイムプリミティブを対象とします。リデューサーの設計、画面のコントラクト、ViewModel の所有権に関する質問は、android-state-management に引き継いでください。
• 対象範囲が広がる場合は、次のスキルに引き継いでください：
• android-state-management
• android-compose-performance

ワークフロー

1. まず問題を分類します：ローカルに記憶する状態、保存する状態、派生状態、ライフサイクルを考慮した収集、または単発の副作用。
2. 問題に合った最も限定的な Compose プリミティブを選びます：remember、rememberSaveable、derivedStateOf、produceState、collectAsStateWithLifecycle、LaunchedEffect、DisposableEffect、SideEffect、または snapshotFlow。
3. 永続的な UI 状態を、スナックバー、ナビゲーション、分析などの一時的なイベントと分けて管理します。
4. エフェクトのキーとコールバック参照を安定させ、再コンポーズによって処理が再起動したり、古いラムダが捕捉されたりしないようにします。
5. Compose ランタイムの問題を切り分けてから、より広範な状態保持オブジェクトの設計を android-state-management に引き継ぎます。

ガードレール

• UI で使用する Flow には、collectAsStateWithLifecycle など、ライフサイクルを考慮した収集を優先します。
• エフェクトを再起動せずに最新のラムダや値を参照する必要がある場合は、rememberUpdatedState を使用します。
• 実際にはイベントである単発のエフェクトを、不変の画面状態に含めないようにします。
• 適切なエフェクト API を使わずに、コンポーザブル本体からコルーチンを起動したり、ナビゲーションを実行したりしないでください。

アンチパターン

• 実際の依存関係が変化したときにエフェクトを再起動すべきなのに、LaunchedEffect(Unit) や不安定なキーを使用する。
• Flow を複数箇所で収集し、イベントが重複する原因を調べることになる。
• 一時的なイベントを画面状態の永続的なブール値として保存し、手動でリセットする。
• 通常の状態読み取りのほうがシンプルで低コストなのに、derivedStateOf や snapshotFlow を使用する。

レビューのポイント

• この動作を担うランタイムプリミティブはどれですか？
• 再コンポーズとエフェクトの再起動は意図したものですか？
• 状態とイベントの経路は別々にモデル化されていますか？
• 収集はライフサイクルを考慮し、キャンセルにも安全ですか？

例

想定どおりのケース

• シナリオ：Compose でタスク状態とスナックバーイベントを収集し、重複した起動を防ぎます。
• コマンド：cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest

エッジケース

• シナリオ：権限状態と同期状態が同時に変化したときの再コンポーズに対応します。
• コマンド：cd examples/orbittasks-compose && ./gradlew :app:assembleDebug

障害からの復旧

• シナリオ：状態とエフェクトの作業を、一般的な Compose のレイアウトや状態管理のリクエストと区別します。
• コマンド：python3 scripts/eval_triggers.py --skill android-compose-state-effects

完了チェックリスト

• 選択した Compose プリミティブが、実際のランタイム上の問題に合っています。
• エフェクトのキーは安定しており、再コンポーズによって重複実行されません。
• 状態とイベントが明確に分けられています。
• より広範なアプリ状態のアーキテクチャに関する作業は、コンポーザブルの修正と混在させずに引き継がれています。

公式リファレンス

• https://developer.android.com/develop/ui/compose/state
• https://developer.android.com/develop/ui/compose/side-effects
• https://developer.android.com/reference/kotlin/androidx/lifecycle/compose/package-summary
• https://developer.android.com/topic/architecture/ui-layer/state-production