molecule: Scheduler breaks keyboard behavior for Compose UI consumers

I put together a sample that allows for easy demoing of the issue and switching between the two clock types. RecompositionClock.Immediate does seem to fix the weird behaviour of input fields.

https://user-images.githubusercontent.com/1245751/182053296-14df5da3-e45b-4747-aa10-fd49e74f3a54.mp4

I have no had a chance to look, no. I can try to look when I’m back working on this library as part of the Kotlin 1.6.20 upgrade to Compose.

Upon further investigation, we’ve settled on a new architecture that slightly disobeys unidirectional data flow to work around this. It turns out that BasicTextField2 encourages consumers of the API to hoist its TextFieldState into the presentation layer. Our team cannot do this since we share our presentation layer between iOS and Android. As a result, we’ve decided that asynchronously sending text field state to our presenters and then back to the text field is an anti-pattern.

Instead, we’ll do a few things differently.

1. Allow the text field to control its own state at the UI layer. Only once it requires action, for example when a submit button is pressed, do we observe the value of that text field and send it to our presentation layer for processing.
2. The value of the text field may be continuously streamed to our presentation layer for auxiliary text field concerns only. Examples of this include text field validation and enabling/disabling form buttons based on the contents of the text fields.
3. Initial values of the text field may be set from a presentation layer model, but once set the text field should maintain its own state in the UI layer until a further action like submitting a form is taken.

For other people encountering this issue in a multiplatform context, I hope our research helps you out.

We were seeing this issue using even the immediate recomposition mode. Switching to use BasicTextField2 seems to resolve the weird interaction.

I got curious about this behavior, and got inspired by watching “Reimagining text fields in Compose” by Zach Klippenstein https://www.droidcon.com/2023/07/20/reimagining-text-fields-in-compose/ to give it a shot to see how these two would play together.

After doing some trials on top of the repro made by Chris Horner, seems like TextFieldState (from BasicTextField2) is what will solve this problem for molecule without having to use the Immediate RecompositionMode.

Also no need to break the UI -> Presenter -> UI as prashanOS described. Nor do you have to have to have another state in the composable UI itself which would effectively create two sources of truth for that text.

This PR that I made here along with the video here shows that it all seems to work well together, while still allowing you to do other async work which doesn’t affect TextFieldState which is also provided to the UI Composable though molecule

The gist is that inside molecule you can do val textFieldState = remember { TextFieldState("") } inside molecule’s body composable and provide it inside your exposed Model directly.

Actually, disregard the previous comment. Tested a bit more. Breaking the ui -> presenter -> ui loop is not necessary. Simply having a mutable state that you update within the onValueChange lambda is sufficient:

@Composable fun EditableText(
    text: String,
    onTextChange: (String) -> Unit,
  ) {
  var localText by remember(text) { mutableStateOf(text) }
  TextField(
    value = localText,
    onValueChange = {
      localText = it
      onTextChange(TextUpdateEvent(it)) 
  })
}