Kotlin Flow: state and event modeling

Core principle

Pick the primitive that matches replay, fan-out, and synchronous-read requirements. StateFlow, SharedFlow, Channel-backed flows, and cold Flow differ in buffering, who sees each emission, and whether .value exists. Wrong choices drop events, leak sharing coroutines, or force fake domain sentinels into state.

When to use this skill

You're writing or reviewing Kotlin code involving:

• MutableStateFlow<T>(SomeSentinel) — NoUser, Empty, Loading, etc. — because the real value is async
• .stateIn(...) called inside a function rather than assigned to a property
• SharingStarted.WhileSubscribed(...) on a flow whose .value is read synchronously and must stay fresh
• MutableSharedFlow for navigation events, snackbars, or other one-shot emissions where loss would be a bug
• .map { } on a StateFlow when consumers still need synchronous .value
• MutableStateFlow.value = _state.value.copy(...) or update code that builds expensive objects inside update { ... }

SharedFlow for single-consumer fire-once events