DEV Community

The discussion has been locked. New comments can't be added.
Post has moved to https://blog.zachklipp.com/a-historical-introduction-to-the-compose-reactive-state-model/
Collapse
 
mr3ytheprogrammer profile image
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.
       }
}
Enter fullscreen mode Exit fullscreen mode

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

Collapse
 
zachklipp profile image
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)
    }
  }
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
mr3ytheprogrammer profile image
M R 3 Y •

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

Collapse
 
aartikov profile image
Artur Artikov •

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

Collapse
 
zachklipp profile image
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.

Collapse
 
lgtout profile image
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.

Collapse
 
aartikov profile image
Artur Artikov •

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

Collapse
 
zachklipp profile image
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".

Collapse
 
lgtout profile image
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!

Collapse
 
lgtout profile image
jabiodun • • Edited

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?