Six parameters deep and none of them are used here
Correct hoisting can still produce an unmaintainable codebase. The four failure modes that show up once a screen grows past a few components, and the fixes for each.
Engineering
Compose, Kotlin, and multiplatform work — the mechanism under the symptom.
229 posts
The ViewModel is not the default place for state. It's the place for state that outlives the screen.
Hoisting to a ViewModel is a different decision from hoisting to a parent composable. The dividing question is lifetime, and getting it wrong in either direction has a specific cost.
State hoisting is one question: who else needs to know?
State hoisting means moving state to the lowest common ancestor of everything that needs it. The trigger is a second reader — not a rule to apply preemptively.
Composition, layout, drawing — and why reading a value in the wrong one costs frames
Compose renders in three phases. Where you read state decides which phase invalidates, and moving a read from composition into layout or draw is the single highest-leverage performance change available.
Your composable ran four times. So did your network call.
A network call written directly in a composable fires an unpredictable number of times. LaunchedEffect, DisposableEffect and SideEffect each define a different notion of when work should happen.
A composable's lifecycle is three events, and none of them is onDestroy
Composables have a lifecycle, but it is nothing like a View's. Three events — enter, recompose, leave — and the identity rules that decide which one you get.
Recomposition doesn't re-run your screen. It re-runs the scopes that read what changed.
Compose does not re-run your whole screen when state changes. It re-runs the smallest restartable scopes that read the changed value. Once you can see those scopes, recomposition stops being mysterious.
What @Composable actually does to your function
@Composable is a compiler plugin that adds hidden parameters to your function. Once you know what it adds, the rules about calling context, skipping and recomposition stop being arbitrary.
Thinking in Compose: you can't reach into the UI any more, and that's the point
In Views you fix UI by reaching in and mutating it. Compose removes that ability entirely. Understanding why the removal is the feature is what makes the rest of Compose make sense.
Compose has two version problems, and the BOM only solves one
The Compose BOM aligns runtime artifacts. The Kotlin/Compose compiler is a separate alignment problem, and mixing the two up produces errors that look like your code is wrong when it isn't.
Basics of Jetpack Compose
What a composable function actually is, the three layout blocks every screen is made of, and how to preview one without running the app.
What is Jetpack Compose?
XML made you invalidate the UI by hand. Compose recomposes only the nodes whose data changed — and that one difference reorders how you build a screen.