Feature request: intelligently capture function parameters from immutable objects [256100927]

Assigned

Feature Request

Status Update

No update yet.

Description

za...@gmail.com

created issue #1

Oct 28, 2022 10:10PM

Jetpack Compose version: 1.3.0

Jetpack Compose component(s) used: compose-compiler

Android Studio Build: N/A

Kotlin version: 1.7.20

Steps to Reproduce or Code Sample to Reproduce:

Example repo: https://github.com/slackhq/circuit

Create a class like this

@Immutable
data class State(val text: String, val sink: (Event) -> Unit)

We have an MVI-ish architecture where we embed event sinks in our state in order to use them as a form of continuation from the UI.

@Composable fun Content(state: State) {
  Column {
    Text(state.text)
    Button(onClick = { state.eventSink(Event.Click) }) {
      Text("Click me")
    }
  }
}

This however doesn't work when the text property changes and results in surprising recompositions of the Button. This is because of lambda capture of the state object and the eventSink identity changing. The workaround is to do this:

@Composable fun Content(state: State) {
  val sink = state.eventSink
  Column {
    Text(state.text)
    Button(onClick = { sink(Event.Click) }) {
      Text("Click me")
    }
  }
}

However, this is obviously a bit annoying. It would be ideal if, in the case of immutable types (and possibly stable types?), the compose compiler could outline the sink function to a local variable like the above automatically and save having to think about this.

Comments

an...@google.com <an...@google.com> Nov 3, 2022 01:28PM

Assigned to le...@google.com.

le...@google.com <le...@google.com> #2Jun 29, 2023 06:04PM

Triage notes: Still P3, still a real issue. Compat issue.

za...@gmail.com <za...@gmail.com> #3Jul 9, 2023 08:14PM

hmm, we actually have moved on from using @Immutable by default since I originally wrote this up, as we wanted to use stable properties without needing to recompose if they didn't change. As a result, only doing this on immutable types would leave most of our states still stuck.

Unfortunately I don't know enough about how the compiler works to be able to offer a concrete proposal, but I do strongly feel that cases like this where the resulting composition is always broken for what seems like a pretty straightforward pattern and not something users can easily solve.

My understanding was that a stable type would not rely on equals() and instead look at its properties individually. If that's not the case, it almost seems like there should be a compiler plugin like Poko (https://github.com/drewhamilton/Poko) that generates equals/hashcode in a way that ignores @Stable/function types.

za...@gmail.com <za...@gmail.com> #4Jul 9, 2023 09:19PM

Another option regarding this

In that case, since it is reading every value of the state object, we could probably further infer that caching by the object is better, but what if the object had 10 properties and we read 9 of them? In that case we either consume a single slot and call a single equals function, or consume 9 slots and 9 equals functions.

What if the compiler created a synthetic class that wrapped all these up? Would that cover the slots?

In general, I do think that "this is expensive but works correctly" is preferable to "this is inexpensive but doesn't work correctly", and I think the latter is the current state given the lack of linting or warnings.

al...@google.com <al...@google.com> Apr 3, 2024 05:51PM

Status: New

al...@google.com <al...@google.com> #5Feb 26, 2025 07:28PM

Assigned to ch...@google.com.

Triage notes: Discussion stalled out two years ago, assigning to Chuck to resume. Note this has 42 votes.

Issue 256100927