Channels
#compose
Title
# compose
j
Joost Klitsie
07/19/2020, 8:47 AMIt seems like text input is lagging behind
I hope you can see it on these videos (On my device the videos are blinking sadly)
but I typed on my keyboard on the emulator:
my name is joostwith dispatchers.main, the final result was:
m name ist jooytwith the immediate dispatcher it worked as expected
Btw I use a
MutableStateFlow<ViewState> Copy code
viewState.value = viewState.value.copy(
userName = userName,
isButtonEnabled = !userName.isBlank() && !viewState.value.password.isNullOrBlank()
)so nothing weird there
a
Adam Powell
07/19/2020, 2:48 PMgenerally speaking the dispatcher shouldn't cause anything to be dropped here.
Dispatchers.Mainj
Joost Klitsie
07/19/2020, 2:50 PM@Adam Powell I'm not saying it is dropping information, I am saying that the information comes in late and therefore messes up the order
Using dispatchers.main means the block will run at the end of the queue
and not directly
the main.immediate will directly run the code if it is triggered on the main thread
I think with the Lifecycle helpers like viewLifecycleScope.launchWhenResumed etc. there was also the update to use the immediate dispatcher so it would behave more like LiveData (which also directly sets the value on setValue instead of posting it to the queue)
I think not using the immediate dispatcher is a bad thing as there is a slight delay between the trigger and actually running the the code block
a
Adam Powell
07/19/2020, 2:58 PMif there is only one source of truth then order is the only thing that matters for correctness, not timing. Information coming in a frame late can't disrupt the order.
j
Joost Klitsie
07/19/2020, 2:59 PMwell in my case (I hope you could see it) it actually messes up the typed text
a
Adam Powell
07/19/2020, 2:59 PMI'm not contesting that updating more promptly is more ideal for other reasons, but if it's affecting order, then using immediate is only masking the other problem you're facing 🙂
j
Joost Klitsie
07/19/2020, 2:59 PMand as I said I don't think I did really weird things
like I use a mutable state flow to store it
is that a weird thing to do?
(I might be wrong in using that component)
a
Adam Powell
07/19/2020, 3:00 PMnot necessarily, depending on how the next value for that MutableStateFlow is computed and how many code paths have write access to it
j
Joost Klitsie
07/19/2020, 3:01 PMin this case, there is only 1 mutable state flow and it is only updated during typing
no other coroutines are launched
a
Adam Powell
07/19/2020, 3:01 PMCan you post some more of the surrounding code from where that update happens?
j
Joost Klitsie
07/19/2020, 3:01 PMwill do
👍 1
Copy code
OutlinedTextField(
value = viewState.userName ?: "",
onValueChange = viewModel::updateUserName,
modifier = Modifier.fillMaxWidth(),
label = { Text("User name") }
)so this is the component
this is in the viewModel:
Copy code
override val viewState = MutableStateFlow(LoginViewState())
override fun updateUserName(userName: String) {
viewState.update {
copy(
userName = userName,
isButtonEnabled = viewState.value.password.isNotNullOrBlack() && userName.isNotNullOrBlack()
)
}
} Copy code
data class LoginViewState(
override var userName: String? = null,
override var userNameError: String? = null,
override var password: String? = null,
override var passwordError: String? = null,
override var isLoading: Boolean = false,
override var isButtonEnabled: Boolean = false
): LoginContract.ViewStatethis is the update function:
Copy code
fun <T> MutableStateFlow<T>.update(
block: T.() -> T
) {
value = value.run(block)
}and this is the viewmodel injection/fetching the view state:
Copy code
@Composable
fun LoginInputComponent(props: LoginContract.Props) {
val viewModel by instance<LoginContract.Props, LoginContract.ViewModel>(props)
LoginInput(viewModel.viewState.collectAsState(Dispatchers.Main.immediate).value, viewModel)
}
@Composable
fun LoginInput(viewState: LoginContract.ViewState, viewModel: LoginContract.ViewModel) {
//... OutlinedTextFieldthe viewmodel is that exact same instance btw anytime this code runs, so no mistakes there
🙂 1
a
Adam Powell
07/19/2020, 3:07 PMthanks, I'm tracing through some of the compose text field source right now to check some theories
j
Joost Klitsie
07/19/2020, 3:07 PM Copy code
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val stateFlow = MutableStateFlow(LoginViewState())
val update = { userName: String ->
stateFlow.value = stateFlow.value.copy(userName = userName)
}
setContent {
val viewState = stateFlow.collectAsState().value
OutlinedTextField(
value = viewState.userName ?: "",
onValueChange = update,
modifier = Modifier.fillMaxWidth(),
label = { Text("User name") }
)
}
}If I rewrite it like this
it is indeed buggy
I think because of the dispatcher, the
updateif it would be the immediate dispatcher, it runs in time
in this I notice when I for example hold backspace, the cursor position shifts
a
Adam Powell
07/19/2020, 3:09 PMI suspect that what you're seeing is something that would happen in any situation where there's a little bit of latency, and ideally I would like our components to be tolerant to that
j
Joost Klitsie
07/19/2020, 3:09 PMyeah makes sense
but it is harder to take into account a method call that just comes in late
This gives no issue at all
Copy code
val viewState = stateFlow.collectAsState(Dispatchers.Main.immediate).valuea
Adam Powell
07/19/2020, 3:10 PMyes, and I would suggest using that as the workaround for now
in this case it depends on what the late method call is operating on. From what I'm reading so far, the text field may be giving you updates based on a stale version of the value that was passed in plus the new changes from the IME
j
Joost Klitsie
07/19/2020, 3:12 PMcould it be that it somehow falls out of the frame because of this:
Copy code
@Composable
fun <T : R, R> Flow<T>.collectAsState(
initial: R,
context: CoroutineContext = Dispatchers.Main
): State<R> {
val state = state { initial }
onPreCommit(this, context) {
val job = CoroutineScope(context).launch {
collect {
FrameManager.framed {
state.value = it
}
}
}
onDispose { job.cancel() }
}
return state
}in combination with the Dispatchers.Main
a
Adam Powell
07/19/2020, 3:14 PMI would prefer it not matter if it happens a frame or three late 🙂
j
Joost Klitsie
07/19/2020, 3:15 PMI'll anyway use the workaround for now. Btw there are a bunch of ripple effects happening on the outlined text field, is that an issue I should report? Or is that a wanted effect on the textfield>?
a
Adam Powell
07/19/2020, 3:16 PMwhat kind of ripple effects?
j
Joost Klitsie
07/19/2020, 3:16 PMWhen I press on the input
there is a ripple
a
Adam Powell
07/19/2020, 3:16 PMnot sure, probably worth filing as a bug just as confirmation
j
Joost Klitsie
07/19/2020, 3:17 PMit looks like the videos I take from the emulator can give people epilepsy so I am not sure that will help 😄
I'll might file a bug in that case!
thanks for your help!
👍 1
a
Adam Powell
07/19/2020, 3:38 PMFor some additional context, the reason I want to double check the IME pathways here is because on Android that process is also very async and we do a lot of work already to make it work within a reactive controlled component framework here
It may be that ensuring less latency in userland is the only way to deal with this but I'd like to know the options and if we can cover for it a bit more if so
Can you do me a quick favor if you have that code still open? If
AndroidUiDispatcherAndroidUiDispatcher.Mainj
Joost Klitsie
07/19/2020, 3:40 PMlemme try!
a
Adam Powell
07/19/2020, 3:40 PMI can't remember if that code made the dev14 build or not
j
Joost Klitsie
07/19/2020, 3:41 PMI see an AndroidUiDispatcher
seems to work well 🙂
a
Adam Powell
07/19/2020, 3:43 PMCool, thanks! That's the dispatcher that you'll get for
launchInCompositionIt does a little more work between Android Handlers and Choreographer to avoid missing a pending frame
Without running synchronously like immediate dispatchers do
j
Joost Klitsie
07/19/2020, 3:46 PMWould you then still need the frameManager?
a
Adam Powell
07/19/2020, 3:47 PMThe FrameManager is kind of a separate concern, and the shape of that is changing over time too. The new Snapshot system replaces Frames and allows for a more streamlined API for dealing with transactions, and also adds a "global transaction" so the "not in a frame" exception is a thing of the past
(also we'll avoid the confusion when talking about a choreographer frame vs. a snapshot frame 🙂)
In short, modifying MutableState off the main thread is a lot easier now
j
Joost Klitsie
07/19/2020, 4:00 PMThat sounds very interesting :) I'd love to read about it when it's done!
a
Adam Powell
07/19/2020, 4:24 PMAfter some further reading through the code and thinking on it again I'm inclined to think that your initial assessment was correct and there's not much we can do in the text components to mitigate what happens if you compress any of our types down to a string and then apply it with latency without tradeoffs that would be much creepier in practice
Sorry, it's been a while since we set this up, apologies that it took me a while to reload the context around it 🙂
I'm the meantime, the issue should go away when we update the collect extensions to use launchInComposition
j
Joost Klitsie
07/19/2020, 4:26 PM@Adam Powell would you suggest the androidUiDispatcher or the immediate dispatcher in this case?
a
Adam Powell
07/19/2020, 4:26 PMFlip a coin. 🙂 Selfishly if the AndroidUiDispatcher introduces any other unexpected side effects I'd like to know early, so feedback there would be welcome
j
Joost Klitsie
07/19/2020, 4:27 PMHaha okay then I'll use that one for you :)
😄 1