A historical introduction to the Compose reactive state model

This post has moved to blog.zachklipp.com.

Comments

[M R 3 Y]

this feature will allow Compose to add parallelism to its execution in the future, without affecting the correctness of code (as long as that code follows the documented best practices, at least).

Isn't that something compose is already doing? for example when you have a LaunchedEffect & any other composable as children of parent composable, AFAIK they will be executed in parallel:

@Composable
fun Component() {
       var state by remember{ mutableStateOf(0) }
       LaunchedEffect(Unit) {
             // do some work which utilizes state's value
       }
       Box() {
             // Use the value of state, too.
       }
}

From my experience with compose I will say that LaunchedEffect & Box will be executed in parallel

[Zach Klippenstein]

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

[M R 3 Y]

Oh! Thanks for clarifying, I got it. I can imagine how powerful this technique could be

[Artur Artikov]

Should we use Compose state management outside of presentation layer? I mean some stateful observable objects in domain or data layers.

[Zach Klippenstein]

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.

[jabiodun]

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.

[Artur Artikov]

Should we use mutableStateOf in ViewModels? Official documentation recommends to use LiveData or StateFlow for some reason: developer.android.com/jetpack/comp...

[Zach Klippenstein]

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".

[jabiodun]

It does this by allowing glue code to control when changes made by one thread are seen by other threads.

What are you referring to as "glue code"?

Thanks!

[jabiodun]

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?