I’ve encountered a problem, which I think is a kno...

# compose

[Alexander Maryanovsky]

I’ve encountered a problem, which I think is a known shortcoming, but I wonder if there are any good general solutions to it.
When a composition is responding to external events (e.g. a key event), and the response depends on and modifies compose “state”, naive code will assume that recomposition will happen between external events, but this is not guaranteed.
<continued in thread>

[Alexander Maryanovsky]

For example, a naive TextField implementation can do something like this

@Composable
fun TextField(
    value: String,
    onValueChanged: (String) -> Unit
) {
    Box(
        modifier = Modifier
           .onKeyEvent { event ->
                onValueChanged(value + event.keyChar)
           }
    ) {
        ...
    }
}

[Alexander Maryanovsky]

But if two key events are received before a recomposition occurs, value will not have changed between them, and so only the last event will actually affect the value.

[Alexander Maryanovsky]

The real TextField implementation uses an internal buffer which it modifies in response to events and resets when a (re)composition occurs.

[Alexander Maryanovsky]

But this is somewhat surprising, and hard(er) to work around if the state is more complex than TextFieldValue.

[Casey Brooks]

Ultimately, you can never be sure of what happens with your onValueChanged. The parent might process the value synchronously, or slowly. It might post the value to another thread for processing. It might completely ignore it. Similar, you can’t ever be sure of what value is either. It might be hardcoded, or in a State variable, or something else. Because of this, your TextField composable shouldn’t assume anything about what happens outside itself.

A safer practice is to either do what the real TextField does and maintain/update a copy of its own internal state which it can make guarantees about, or else be completely passive and only pass the keyEvent up, so that whatever parent is listening for the value can append it to the value State itself.

[Casey Brooks]

I find the MVI pattern to be really helpful for safely managing updates to complex states. You wrap each possible change to the state into some “Input” type, and from a central location at the root of your UI screen process each change one-by-one with the previous State, producing a new State. You get guarantees that each update is atomic, and if you use sealed classes to wrap your “inputs”, you can pass multiple types of updates through a single (Input)->Unit lambda passed through the whole UI tree.

[Alexander Maryanovsky]

I don’t think the problem here is that the code assumes anything about onValueChanged. The problem is in the timing of receiving feedback from onValueChanged. By the way, using an internal buffer with onValueChanged = {} can actually be problematic, as it will continue to fill up. Not entirely sure how TextField deals with it.

[Alexander Maryanovsky]

Passing Input up the tree can work for an application, but not for a standalone utility widget.

[Casey Brooks]

The code assumes that there will be some parity between value and how it processes onValueChanged, but you don’t actually know that they two are related. But if know you’re working directly with a State, you get lots of guarantees about the value and ordering of the data within a local context.

For example, onKeyEvent gets dispatched on the UI thread, and States will immediately reflect whatever value you set on the same thread. So multiple quick updates to an internal State will correctly order and update those events, since they’re in the same thread, and therefore see the same Snapshot.

But if the value is passed up to a parent composable, Compose doesn’t know that value and onValueChanged are meant to be part of the same snapshot from within the TextField, so it can’t guarantee that calling onValueChanged is synchronous with respect to value, and so you only get a new value upon recomposition.

[Casey Brooks]

This snippet is effectively the “internal buffer” that the Material TextField uses.

@Composable
fun TextField(
    value: String,
    onValueChanged: (String) -> Unit
) {
    val _state by remember(value) { mutableStateOf(value) }

    Box(
        modifier = Modifier
           .onKeyEvent { event ->
                _state = _state + event.keyChar
                onValueChanged(_state)
           }
    ) {
        ...
    }
}

[Alexander Maryanovsky]

That will have a problem if called with onValueChanged = {} or more realistically perhaps something like

onValueChanged = { value = it.substring(0, 10) }

trying to limit the TextField to 10 characters.

[Alexander Maryanovsky]

But anyway, I understand the buffer workaround. I was wondering if there’s a more general solution.

[Casey Brooks]

I’m not sure if this would work, but one solution might be to pass the value in as a lambda, rather than a specific value. So that each time onKeyEvent is called, it’s fetching the latest value from the State where it is stored and which receives the onValueChanged update, rather than working with the composed value

[Alexander Maryanovsky]

Or just pass the State (but that’s frowned upon)

[Casey Brooks]

The cleanest solution to integrate into the rest of your app is probably to move the necessary logic (like character limit) into the TextField and manage its own state internally. Passing the value as a lambda is definitely some non-standard Compose code, too, just like passing the State directly

[Zach Klippenstein (he/him) [MOD]]

This is why we’re exposing TextFieldState for the BasicTextField rewrite

[Alexander Maryanovsky]

So the advice is to always pass a state wrapper?

[Zach Klippenstein (he/him) [MOD]]

I don’t know about “always”, but to solve this, probably yea. With TextFieldState you can modify the state whenever and it will immediately be visible to anything using the state.