MVI Pattern Flashcards
ARCHITECTURE › Patterns
- What are the three core elements of MVI?
- Model (a single immutable state object for the screen), View (renders that state), and Intent (user actions or events modeled as objects). State flows down to the View, intents flow up.
- What is a reducer in MVI and what signature does it have?
- A pure function that takes the current state and an intent/result and returns a new immutable state: (state, intent) -> newState. Being pure, it does no I/O and is trivial to unit test.
- Why does MVI insist on a single immutable state object per screen?
- One source of truth prevents inconsistent partial states, every render reflects exactly one state value, and because copies are immutable you can log, diff, and replay each transition for debugging.
- How does MVI enable time-travel debugging?
- Every state is an immutable snapshot produced by a deterministic reducer, so you can record the ordered list of states and intents and step backward/forward or replay them to reproduce a bug exactly.
- How are side effects handled in MVI?
- Async work (network, DB) runs outside the reducer; its outcome is dispatched back as a new intent/result that the reducer folds into state. One-off events (navigation, toasts) are modeled either as a consumable field in state or a separate effect channel.
- How does MVI differ from MVVM?
- MVVM exposes state (often several observable properties) and lets the View call arbitrary ViewModel methods. MVI funnels all interaction through a single intent entry point and one immutable state, making transitions explicit at the cost of more boilerplate.
- What is the main tradeoff of adopting MVI?
- It adds boilerplate: state classes, intent/event sealed hierarchies, a reducer, and effect plumbing. The payoff is predictability and debuggability, so it shines on complex stateful screens and is overkill on trivial ones.
- Per Android guidance, why avoid emitting one-off events from the ViewModel to the UI?
- Events sent to the UI can be lost or mishandled across lifecycle/config changes. The guidance is to process them in the ViewModel and reduce the result into state, keeping a single source of truth.
- How do Compose and StateFlow map onto MVI?
- The immutable UiState is exposed as a StateFlow (or mutableStateOf) and collected with collectAsStateWithLifecycle; the composable calls an onIntent/onEvent lambda, giving the state-down/intent-up loop natively.