Why You Should Stop Passing ViewModels Around Your Compose UI Tree ðŸš«

 Master State Hoisting and the "Route-level" pattern to build scalable, testable, and preview-friendly Android apps.

Why You Should Stop Passing ViewModels Around Your Compose UI Tree

If you’ve been building with Jetpack Compose for a while, you know how tempting it is to just pass a ViewModel instance down through five layers of UI components. It’s convenient—one object gives you all the data and all the functions you need.

But here is the architectural reality: Passing ViewModel instances deep into your UI tree is an architectural anti-pattern. It couples your visual components to business logic and makes your code significantly harder to maintain, test, and preview.

The Core Problem: Lifecycle and Scoping

ViewModels are designed to be state holders tied to a specific lifecycle (usually a Navigation Destination). When you pass a ViewModel into a small UI component, you break the Unidirectional Data Flow (UDF).

❌ The “Bad” Way (Tight Coupling)

// ❌ BAD: This component is now impossible to preview or reuse
@Composable
fun ProfileHeader(viewModel: UserProfileViewModel) {
    Text(text = viewModel.userName) 
}

✅ The “Better” Way (Stateless)

// ✅ BETTER: Just pass the data you need
@Composable
fun ProfileHeader(userName: String) {
    Text(text = userName)
}

The Solution: State Hoisting & Immutable UI State

The gold standard in Compose is State Hoisting. Instead of the child component reaching out for data, the parent “hoists” the state up and passes down only what is necessary: Immutable State and Lambda Callbacks.

The Expert Pattern: Route vs. Screen

To build scalable apps, we distinguish between the Route (the logic connector) and the Screen (the visual layout).

  • Route-level: Handles DI, ViewModel injection, and lifecycle observation.
  • Screen-level: A stateless Composable that only knows about data classes and lambdas.
// 1. Define an immutable snapshot of the UI
data class UserProfileUiState(
    val userName: String = "",
    val bio: String = "",
    val isFollowing: Boolean = false
)

// 2. The ViewModel manages logic using StateFlow
class UserProfileViewModel : ViewModel() {
    private val _uiState = MutableStateFlow(UserProfileUiState())
    
    // StateFlow is the standard for ViewModels (Lifecycle-aware & Testable)
    val uiState: StateFlow<UserProfileUiState> = _uiState.asStateFlow()

    fun toggleFollow() { /* Logic updates _uiState */ }
}

// 3. The ROUTE observes the ViewModel
@Composable
fun UserProfileRoute(viewModel: UserProfileViewModel = hiltViewModel()) {
    // collectAsStateWithLifecycle stops collection in the background
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    UserProfileScreen(
        uiState = uiState,
        onFollowClick = { viewModel.toggleFollow() }
    )
}

🛠️ Recommended Project Template

To enforce this boundary, structure your feature folders like this:

ui/feature_profile/
├── ProfileViewModel.kt      // StateFlow logic
├── ProfileUiState.kt        // Immutable data snapshot
├── ProfileRoute.kt          // Logic/DI Boundary
├── ProfileScreen.kt         // Stateless UI Layout
└── components/              // Small, reusable, "dumb" widgets
    ├── ProfileHeader.kt
    └── FollowButton.kt

💡 Architectural Nuances

  • StateFlow vs. mutableStateOf: Use StateFlow in ViewModels for better testing and platform independence. Save mutableStateOf for local UI state (like a toggle switch that doesn't need business logic).
  • Prop Drilling: If you have too many arguments, don’t reach for the ViewModel! Group your data into Nested UiStates or group callbacks into a single action interface.
  • Immutability: Never mutate UiState properties. Always use .copy() to emit a new snapshot. This is the "secret sauce" for Compose performance.

Why This Wins: Effortless Previews & Testing

Because your UI is now Stateless, you can visualize every state — Loading, Error, or Success — without ever running an emulator.

Multiple Previews for Different States

@Preview(name = "Following State", showBackground = true)
@Composable
fun PreviewFollowing() {
    UserProfileScreen(
        uiState = UserProfileUiState(userName = "John", isFollowing = true),
        onFollowClick = {}
    )
}

High-Speed UI Testing

Testing becomes a breeze because you don’t need to mock a ViewModel or handle Coroutine Dispatchers.

@Test
fun profileScreen_showsUsername() {
    composeTestRule.setContent {
        UserProfileScreen(
            uiState = UserProfileUiState(userName = "Jane Doe"),
            onFollowClick = {}
        )
    }
    composeTestRule.onNodeWithText("Jane Doe").assertExists()
}

🙋‍♂️ Frequently Asked Questions (FAQs)

Is it ever okay to pass a ViewModel down?

In software architecture, “never” is rare. For a tiny internal tool or temporary scaffolding, it might be fine. But for production apps, sticking to this principle prevents technical debt.

Should I use CompositionLocal to avoid prop drilling?

Use CompositionLocal for truly global data (Themes, User Sessions). Do not use it as a hidden tunnel to pass ViewModels or screen-specific state; that makes your code "magical" and hard to debug.

🎯 Your Weekend Challenge

Pick one screen in your app. Extract the ViewModel logic into a Route and make the rest of the screen Stateless. You’ll notice your Previews start working again instantly!

Happy coding! ðŸš€

📘 Master Your Next Technical Interview

Since Java is the foundation of Android development, mastering DSA is essential. I highly recommend “Mastering Data Structures & Algorithms in Java”. It’s a focused roadmap covering 100+ coding challenges to help you ace your technical rounds.


Comments

Post a Comment

Popular posts from this blog

Stop Writing Massive when Statements: Master the State Pattern in Kotlin

Image
 Tame Your Codebase with Elegant, Scalable, and Type-Safe State Machines Do you manage complex objects that change their behavior dramatically based on their internal status? If so, you’ve likely battled a common foe: the sprawling  when  statement that haunts every method in your class. It looks something like this: fun handleAction () { when (state) { State.A -> { /* logic for A */ } State.B -> { /* logic for B */ } State.C -> { /* logic for C */ } // ... and the list keeps growing! } } Every time you add a new state (e.g.,  State.D ), you have to hunt down and update  every single function  with a new case. This is a maintenance nightmare, a direct violation of the  Open/Closed Principle  (OCP), and a major code smell. Your logic is scattered by  action  when it should be grouped by  state . The solution? The  State Pattern . And with modern Kotlin, we can implement it w...
Read more

Coroutines & Flows: 5 Critical Anti-Patterns That Are Secretly Slowing Down Your Android App

Image
 Stop sneaky performance killers. Spot and fix Kotlin issues that cause crashes, memory leaks, and laggy UIs. Coroutines and Kotlin Flows are the bedrock of modern asynchronous programming on Android. They allow us to write clean, sequential-looking code that manages complex background operations, network calls, and database transactions. But power comes with responsibility. Many developers, despite using Coroutines daily, unknowingly introduce subtle mistakes —  anti-patterns  — that lead to memory leaks, silent crashes, data loss, and UI jank. Based on insights from top-tier Android development, here are five critical Coroutine and Flow anti-patterns you must identify and fix today, plus one bonus pitfall I often see in code reviews. 1. The Main Thread Trap: Heavy Work in  viewModelScope When you launch a coroutine inside a  ViewModel  using  viewModelScope.launch { ... } , where do you think that work runs by default? The  Main Thread ! If your...
Read more

Master Time with Kotlin's Stable Timing API: Beyond System.nanoTime()

Image
 Learn how to use type-safe Durations, measure execution time, and simplify unit testing with Kotlin 1.6+. Managing time in software is a ubiquitous challenge. From measuring performance to scheduling events, accurate and robust timing is crucial. For years, many Kotlin developers relied on manual  Long  calculations with  System.nanoTime() . While functional, this approach was prone to unit confusion and lacked type safety. Enter the  stable  kotlin.time  API  (fully stable since Kotlin 1.6). This powerful toolset provides a type-safe, idiomatic, and highly readable way to handle durations. It eliminates the guesswork and boilerplate, allowing you to write cleaner, more maintainable code. Quick Tip:  To follow along with the examples below, you’ll want to include this import at the top of your file:  import kotlin.time.* Why Ditch Manual Long Calculations? Imagine you’re tracking the execution time of a critical network request using th...
Read more