Hello there, Is it Safe to Include Lambdas in Jetpack Compose UI State? (more details in :thread::ar...

# compose

[casablancais]

Hello there,
Is it Safe to Include Lambdas in Jetpack Compose UI State? (more details in 🧵⤵️)

[casablancais]

I'm working with Jetpack Compose for my app and have come across a scenario where I find it convenient to store lambdas as part of my UI state. Specifically, I have a data class that represents the state of a UI component, and in addition to traditional state data like Strings or Integers, I have lambdas for handling certain events.

data class MyTextFieldUiState(
    val value: String = "",
    val onFocusIsLost: () -> Unit = {},
    val onValueChange: (String) -> Unit = {}
)

I utilize this state in a Composable as follows:

@Composable
fun MyTextField(uiState: MyTextFieldUiState) {
    TextField(
        value = uiState.value,
        onValueChange = { newValue ->
            uiState.onValueChange(newValue)
        },
        modifier = Modifier.onFocusChanged { focusState ->
            if (focusState == FocusState.Inactive) {
                uiState.onFocusIsLost()
            }
        }
    )
}

My concerns are:
1. Does having lambdas as part of the state lead to any unexpected recompositions?
2. Is there a potential performance hit?
3. Is this pattern considered a best practice, or is there a more recommended way to handle event callbacks in Compose?
Any insights would be much appreciated!

[xoangon]

AFAIK, that lambda should be stable and you should have no performance penalty. However, the best way to check this out is by using the Compose compiler metrics

[Christiano]

I'd recommend to take a look at this. Getting events from the UI to the ViewModel (or vice versa) would be done with new objects (sealed classes) for UIEvents or regular Events.

For a YouTube reference you can always take a look at the

Philip Lackner's▾

stuff. He uses this pattern a lot.

https://developer.android.com/topic/architecture/ui-layer/events

[Benoit Quenaudon]

I don’t recommend this practice. One big reason would be that testing is a pain here. How do you test your emitted model?
How do you confirm the lambda has the right behavior? And that’s gonna be even more painful to test the more it needs parameters.
I’d emit

data class MyTextFieldUiState(
    val value: String = "",
)

and
the view would simply expose two events data object OnFocusIsLost and data class OnValueChange(string) which the presenter would react to.

[Benoit Quenaudon]

I think some people on our team did that and the past and they understood the pain. We dont’ have any anymore in our codebase.

[Benoit Quenaudon]

And yo how would you test the lambda? You have to emit a model first, consume that model, and execute the lambda !?

[Benoit Quenaudon]

That’s what tests should look like

[casablancais]

And yo how would you test the lambda? You have to emit a model first, consume that model, and execute the lambda !?

I will obtain an initial state, execute the lambda, and verify if the ViewModel/Presenter sends a new state with a new value.
You are right; ensuring that the ViewModel/Presenter is in the correct state before executing the lambda can be a challenging task.

[Stylianos Gakis]

Benoit, is this last slide from some talk/presentation? It looks like it from the text being cut/off from the top-right. If yes I’m curious to see the rest of it too 😊

[Benoit Quenaudon]

It’s just a link to the molecule library https://github.com/cashapp/molecule

[Stylianos Gakis]

Oh alright, but did this screenshot come from some presentation? That's what I was wondering 👀

[Benoit Quenaudon]

https://speakerdeck.com/oldergod/sweet-architecture

https://www.youtube.com/watch?v=mbYzcF43fbc▾

[Stylianos Gakis]

Thanks a lot!