Are there cases where it’s better to consume a value as compose.runtime.State?

[shaharKeisarApps]

In our app, we noticed unnecessary recompositions when using TextField components. Specifically, passing the value as a plain TextFieldValue caused recompositions in unrelated parts of the UI - I think that's because Compose determines whether to recompose based on equality checks.
However, switching to State isolated the recompositions to only the relevant composables.

I have edited the tutorial example to demonstrate this:

@Composable
fun Inbox(state: InboxScreen.State, modifier: Modifier = Modifier) {
    Scaffold(
        modifier = modifier,
        topBar = { TopAppBar(title = { Text("Inbox") }) }) { innerPadding ->
        LazyColumn(modifier = Modifier.padding(innerPadding).fillMaxSize()) {
            item {
                EmailSearch(state.searchQuery) { query ->
                    state.eventSink(InboxScreen.Event.SearchQueryChanged(query))
                }
            }
            items(state.emails) { email ->
                EmailItem(
                    email = email,
                    onClick = { state.eventSink(InboxScreen.Event.EmailClicked(email.id)) },
                )
            }
        }
    }
}

@Composable
private fun EmailSearch(query: State<String>, onQueryChanged: (String) -> Unit) {
    TextField(
        modifier = Modifier.fillMaxWidth().height(48.dp),
        value = query.value,
        onValueChange = onQueryChanged,
        label = { Text("Search") },
    )
}

Is there something I'm missing by understand how Compose update the UI?, or other benefits to consume it as the value itself.

[ZacSweers]

Circuit state only has to be Stable, you can use stable properties in circuit state classes if you want. That said, the same standard compose design guidelines kick in here. Use callbacks, avoid passing state directly, etc. If you've measured this and found a meaningful performance issue, you could explore writing your state as an interface backed by state objects for this specific use case. But again - *if you've measured this.

[shaharKeisarApps]

Interestingly, it was a new developer on our team who came from a TV platform background that brought this to my attention. On TVs, where resources are much more constrained, even small inefficiencies tend to stand out. It got me curious, and I noticed the recomposition behavior in places like TextField.

That said, I really appreciate the clarification! Our app is entirely based on the regular value consumption approach (TextFieldValue), and we haven’t noticed any performance issues so far. I’ll definitely do some measurements to check if there’s a meaningful difference.

And yeah, I’m sure you’ve seen this come up at Slack too—TextField usage there must be off the charts! 😅

Thanks for the great insights!

I hope this post answers the concerns of the curious.

[shaharKeisarApps]

@ZacSweers I’m curious about the reasoning behind "avoid passing state directly." Could you elaborate on why this is considered a best practice?

If you have any recommendations for articles or places in the Compose runtime code where I can read more about this, that would be super helpful. Thanks in advance!

[ZacSweers]

https://developer.android.com/develop/ui/compose/state-hoisting