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(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
Show more
Installs
424
Repository
chrisbanes/skills
GitHub Stars
732
First Seen
May 12, 2026
Security Audits
Gen Agent Trust Hub
Pass
Socket
Pass
Snyk
Pass