compose-multiplatform-patterns

Compose Multiplatform and Jetpack Compose patterns for KMP projects — state management, navigation, theming, performance, and platform-specific UI. Use when building Compose or Jetpack Compose UI, state, navigation, or theming in a KMP project.

By affaan-m · 2,902 installs

npx skills add affaan-m/ecc --skill compose-multiplatform-patterns

Source repository · Upstream listing

Compose Multiplatform Patterns Patterns for building shared UI across Android, iOS, Desktop, and Web using Compose Multiplatform and Jetpack Compose. Covers state management, navigation, theming, and performance. When to Activate Building Compose UI (Jetpack Compose or Compose Multiplatform) Managing UI state with ViewModels and Compose state Implementing navigation in KMP or Android projects Designing reusable composables and design systems Optimizing recomposition and rendering performance State Management ViewModel + Single State Object Use a single data class for screen state. Expose it as StateFlow and collect in Compose: Collecting State in Compose Event Sink Pattern For complex screens, use a sealed interface for events instead of multiple callback lambdas: Navigation Type Safe Navigation (Compose Navigation 2.8+) Define routes as @Serializable objects: Dialog and Bottom Sheet Navigation Use dialog() and overlay patterns instead of imperative show/hide: Composable Design Slot Based APIs Design composables with slot parameters for flexibility: Modifier Ordering Modifier order matters — apply in this sequence: KMP Platform Specific UI expect/actual for Platform Composables Performance Stable Types for Skippable Recomposition Mark classes as @Stable or @Immutable when all properties are stable: Use key() and Lazy Lists Correctly Defer Reads with derivedStateOf Avoid Allocations in Recomposition Theming Material 3 Dynamic Theming Anti Patterns to Avoid Using mutableStateOf in ViewModels when MutableStateFlow with collectAsStateWithLifecycle is safer for lifecycle Passing NavController deep into composables — pass lambda callbacks instead Heavy computation inside @Composable functions — move to ViewModel or remember {} Using LaunchedEffect(Unit) as a substitute for ViewModel init — it re runs on configuration change in some setups Creating new object instances in composable parameters — causes unnecessary recomposition References See skill: android clean architecture for module structure and layering. See skill: kotlin coroutines flows for coroutine and Flow patterns.