When I have this bit of code ```MyComposable(stat...

# compose

[dimsuz]

When I have this bit of code

MyComposable(state, onClick = { someObject.sendEvent() })

and state is immutable, but someObject is not `Stable`/`Immutable`, (for example it can be a ViewModel or Presenter) this leads to constant recompositions, because onClick is not considered a Stable lambda. I confirmed this: my code stops constantly recomposing MyComposable if I make onClick empty.

What is the recommended refactoring to avoid such issues? Marking someObject as Stable is not always possible or often incorrect.

[ephemient]

https://multithreaded.stitchfix.com/blog/2022/08/05/jetpack-compose-recomposition/

[dimsuz]

This article helped me remember this issue, I now went and re-read its corresponding recommendation section on how to handle this problem. thanks!

[dimsuz]

I've used a combination of method-references and remembering lambdas and it seems to help.

This stuff is really not obvious I hope in future tooling can somehow hint about this.

[Zoltan Demant]

How far does this stretch? As an example, consider a "viewmodel" that lives outside of compose and provides a (Event) -> Unit callback for every state it produces. The lambda encapsulates some repository which is unstable. So the lambda is now unstable as well? 🤔

[dimsuz]

I find it best to think of this in terms of lambda being compiled to class instance:

class SomeLambda(val viewModel: ViewModel) {
  fun invoke() {
    viewModel.callback(event)
  }
}

if you have something like this, then repostitory will not be a property of SomeLambda class, so it will not pariticipate in compose's desicion on wheter onClick: SomeLambda argument is stable or not.

[Zoltan Demant]

Thats a great way to put it! Given that the viewmodel is also unstable, I take it that the lambda will be unstable all the time as well. This is a bit of a surprise to me, but it makes sense.

The article mentions that you can work around this by remembering the lambda. Using the same example I gave above, if the viewmodel instead declares the lambda (rather than creating a new one for each state), that should give the same result?

[ephemient]

depends on the key to remember

[Zoltan Demant]

Its both scary and awesome to think that such a small tweak can make such a big difference in the world of compose. I wouldve never thought that this was the reason why some of my animations werent super-smooth (I posted about it the other day). Changing from a fun interface that accepts <Event> to a value class that wraps a lambda made a huge difference for me. It did not make any difference whether I was creating them on the fly or keeping the same instance around in the class (or remembered). Thanks for bringing this to my attention! fist bump