A historical introduction to the Compose reactive state model

That’s true, and my wording wasn’t as precise as it should have been. You are correct that effects can already be used to run code in parallel to composition.

What I intended that sentence to mean was that Compose can perform composition of multiple composables in parallel. It does not currently do this - when preparing a frame, all invalidated composable functions are currently recomposed in a loop on the main thread. Experimental support for parallel recomposition is already present but you have to opt in to it using fairly low level APIs.

So, for example, in this code, when state is changed, the lambdas passed to box 1 and box 2 would both be invalidated, and then they could both be re-executed on different background threads. Right now they’d be executed serially on the main thread.

@Composable fun Root() {
  val state by remember { mutableStateOf(…) }
  Column {
    // Box 1
    Box {
      println(state)
    }
    // Box 2
    Box {
      println(state)
    }
  }
}

I don't personally have a strong opinion here. If it makes sense, and it makes the code cleaner/more testable/easier to maintain, then sure.

This is a very interesting idea. What might that look like? Can you elaborate a bit more? I imagine this would replace either RxJava or Flow on these lower layers.

It depends how much you want to couple your ViewModels to the Compose runtime and mental model. I do wish the snapshot stuff was in a separate artifact so this would be an easier call. I would see no reason to not use snapshot state in view models in a 100% compose app. I also think that in such an app, "view model" is basically interchangeable with/just another word for "hoisted state class".

Re-reading the post more closely, is this the answer to my question?

It might not be immediately obvious in such a simple example, but this is a huge improvement over the RxJava approach because the code to wire up initialize only needs to be written once (e.g. in a base class or factory function) and it will automatically work for all code using that infrastructure.

Is "glue code" generic infrastructure code to make any state observable?