Hey everyone, how are you today? Have a question a...

# compose-android

[Lucas Villa Verde]

Hey everyone, how are you today?
Have a question about best practices for one-time event pattern
Let's say I have the following code for this case:

val 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]

You could consider wrapping the flow in a stable wrapper class if you need to pass it very deep. You shouldn't calculate anything heavy in recomposition, you should generally memoize any heavy calculation with remember to avoid performance issues with recomposition. (Light calculations do not need to be remembered because remember causes its own overhead.)

[vide]

If you know what you are doing, you can do something like this:

@Stable
class StableWrapper<T> (var it: T)

[Lucas Villa Verde]

You could consider wrapping the flow in a stable wrapper class if you need to pass it very deep

Thank 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]

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.

[vide]

Using lambdas is quite dangerous as well if you're really looking to hand-optimize performance because of the way the compose compiler optimizes lambdas. You will get a new lambda every time if you reference an unstable value in the closure of the lambda, which will then not skip recomposition because it's a different instance every time. For example

val 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 })

[vide]

So if you want to use the function provider approach, you should write it like this:

MyComposable(provideEventFlow = remember(flow) { flow })

[vide]

I'm not going to recommend either way since it depends so much on the use case, but I want to bring up additional considerations you might not be aware of blob smile

[Lucas Villa Verde]

> So if you want to use the function provider approach, you should write it like this:
>

MyComposable(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.