English for Jetpack Compose Developers

Jetpack Compose’s declarative model replaced Android’s imperative View system with a vocabulary borrowed from reactive UI frameworks — recomposition, state hoisting, side effects — but applied to Kotlin in ways that trip up even experienced Android developers. Getting this vocabulary right matters in code review, where a vague description of “the UI updates weirdly” usually hides a specific, nameable recomposition bug. This guide covers the English used when discussing Compose code with a team.

Key Vocabulary

Recomposition — the process of Compose re-running a composable function to reflect updated state, ideally re-running only the smallest necessary part of the UI tree. “This composable is recomposing on every keystroke because it reads the entire form state object instead of just the one field it displays.”

State hoisting — moving state up to a composable’s caller so the composable itself becomes stateless and reusable, receiving the value and an event callback instead of owning the state. “Let’s hoist this state up to the parent — right now the component can’t be reused anywhere else because it owns its own internal state.”

Side effect (in Compose) — code that reaches outside the composable’s scope (like a network call or a log write), which must be wrapped in an effect handler such as LaunchedEffect so it runs at the right point in the lifecycle rather than on every recomposition. “That network call is running directly in the composable body — it needs to be inside a LaunchedEffect keyed on the ID, or it’ll refire on every recomposition.”

Stability — a property of a type indicating the compiler can trust its equality checks to skip recomposition when the value hasn’t meaningfully changed; unstable types force recomposition more often than necessary. “That data class has a var field, which makes it unstable — the compiler can’t safely skip recomposition, so every part of the tree using it recomposes unnecessarily.”

Composable function — a function annotated @Composable that emits UI, callable only from other composables, and which Compose can call, skip, or re-run as needed. “You can’t call this composable from a regular click listener directly — it needs to be invoked from within the composition, not from an imperative callback.”

Remember — a Compose API that caches a value across recompositions so it isn’t recalculated or reset every time the composable re-runs, distinct from state surviving configuration changes. “Wrap that expensive calculation in remember so it only runs once per composition instead of on every recomposition.”

Common Phrases

• “Why is this recomposing so often — is it reading more state than it needs?”
• “Should this state be hoisted up to the parent instead of owned locally?”
• “Is this side effect wrapped in LaunchedEffect, or is it running directly in the composable body?”
• “Is this type stable, or could that be causing unnecessary recomposition?”
• “Did we wrap this in remember, or is it being recalculated every recomposition?”

Example Sentences

Reviewing a pull request: “This composable takes the whole UiState object as a parameter, but it only uses one field — let’s pass just that field so it doesn’t recompose every time an unrelated part of the state changes.”

Explaining a design decision: “We hoisted the search query state up to the screen level, so both the search bar and the results list can react to it without either one owning it directly.”

Describing a bug: “The API call was firing repeatedly because it lived directly in the composable body — wrapping it in LaunchedEffect(id) fixed it, since that only re-runs when the key changes.”

Professional Tips

• Say “recomposition” specifically rather than “re-render” when discussing Compose — it’s the framework’s own term and signals familiarity with its execution model.
• When reviewing a composable, ask “what state is this reading, and does it need all of it?” — this is the standard framing for diagnosing over-recomposition.
• Use “stable” and “unstable” precisely when discussing performance — these are compiler-recognized terms, not general adjectives.
• Distinguish “remember” (survives recomposition) from “rememberSaveable” (also survives configuration changes and process death) when explaining state persistence choices.

Practice Exercise

1. Explain in two sentences why an unstable data class parameter can cause excessive recomposition.
2. Write a one-sentence code review comment recommending state hoisting for a non-reusable composable.
3. Describe, in your own words, why a network call inside a composable body needs LaunchedEffect.