Lucas Villa Verde
10/09/2023, 4:51 PMval focusRequester = remember { FocusRequester() }
UIEventFlow.collect {
if (it is RequestFocusEvent) {
focusRequester.requestFocus()
}
}
Since I would need to pass a Flow
in my parameters, this would make my composable unstable and it will not skip recomposition. This could lead to some inconsistencies specially if I want to work with custom Modifiers, key events or even performance issues if I'm calculating something specific at every recomposition.
I thought about converting this to some kind of state, but feels strange since it's really an event.
Do you have any hints or recommendations for solving this case?vide
10/10/2023, 9:34 AMremember
to avoid performance issues with recomposition. (Light calculations do not need to be remembered because remember
causes its own overhead.)@Stable
class StableWrapper<T> (var it: T)
Lucas Villa Verde
10/10/2023, 9:39 AMYou could consider wrapping the flow in a stable wrapper class if you need to pass it very deepThank you and good suggestion! I thought about hoisting a lambda provider as well, something like
provideEventFlow: () -> Flow<UIEvent>
which would avoid the recomposition as well.
Also after reading this article I'm not quite sure if I agree to turning those kind of UI interactions to states 🤔vide
10/10/2023, 10:48 AMval flow: Flow = [...]
MyComposable(flowProvider = { flow })
will cause MyComposable to not skip, because the lambda instance is recreated every time. When referencing stable values, the compiler automatically generates a remember around the lambda like this:
// your source
val flow: StableFlow = [...]
MyComposable(flowProvider = { flow })
// compiler output:
val flow: StableFlow = [...]
MyComposable(flowProvider = remember(flow) { flow })
MyComposable(provideEventFlow = remember(flow) { flow })
Lucas Villa Verde
10/10/2023, 11:01 AMMyComposable(provideEventFlow = remember(flow) { flow })
Yup, this is exactly what I did, thanks so much for all the information and context here.
> I think that article should be taken with a grain of salt in the context of focus interactions, thinking about reducing events to change in "focus state" is not very simple.
I agree with that, but it's indeed a tricky one showing regular and simple situations as examples and people start to use that as a rule, which IMO is not the case for many different situations.