I’ve must have missed something about how the UI updates are handled. Before (when the magic of @Model existed) I could change the data model outside a @compose scope (data pushed via FCM) and it automatically updated the UI. Without that magic, I should according to the migration guide, I should use

by state

or

mutableStateOf

together with

remember

, both of them reassign the datamodel to a wrapped variable inside the @Compose scope and i’m not sure how to mutate the data class and force a refresh.

It's the same as before, but instead of annotating the class owning the fields, you change the fields to

MutableState

delegates. So before if you had

var foo = Foo()

in your

@Model

class, you need to change that to

var foo by mutableStateOf(Foo())

. Then you use this class the same way as before.

state

is a shortcut to

remember { mutableStateOf(e) }

and

remember

is only meaningful in a

@Composable

so you can't use that delegate in a model class.

I guess i have to change from

@Model
data class Model(
  var loading: Boolean = true
)

to

class Model(
  loading: Boolean = true
) {
  var loading by mutableStateOf(loading)
}

Which (if this is correct) makes data classes unsuitable for compose models?

Yeah, I'd say so

makes data classes unsuitable for compose models

Mutable data class already not the best choice in general

True, but it just felt like I had to add a lot more plumbing code (which is true, but maybe for a good reason)

maybe this would be better:

class Model {
  var loading by mutableStateOf(false)
}

fun someInit(model: Model) {
   model.apply {
       loading = true
   }
}

you’re right, most of the time there is a default that you can fall back to, and if not, you can always

apply

the changes directly when you create the instance the first time.

Otherwise if this is state from outside, the most natural thing might just be to just send down a Flow or equivalent with the data and then collect in the composition with collectAsState

Yes, to populate it definitely better, but to update this state you need quite different unidirectional data flow architecture, which quite a different thing

fwiw, an @Model data class was already pretty weird in the first place. data classes still work great with compose in general, and promote immutable types (which we like). If you want to use data classes i encourage it, but I would hold on to them in a

State<MyDataClass>

and then instead of mutating the data class, you would use something like

.copy(…)

to produce a new one and assign the state object to the new value

If I move them to state objects, wont they be “locked” to the @compose scope again, making it harder to update them from the “outside”, like from FCM? I still think the documentation are missing these kind of examples. Simple case, The Activity starts, sets the content, opens a Viewmodel that loads the data and then I want the new data to update specific parts of the view. I might have missed these examples, but normally I find either “click a button to update a field” or ” this is a full app that you can play with” and few things in between.

val x = mutableStateOf<Thing>(someThing)

Right now there is extra work you need to do in order to assign x.value outside of the main thread, but there is nothing about

x

that says a composition has to exist or that it has to do with composition at all. If you want to assign it outside of the main thread, right now you will need to use

FrameManager.framed { x.value = newValue }

BUT, this is changing. We just landed a big refactor to the way all of this works and now

FrameManager.framed

is not needed and you can assign

x.value

in any thread at any time. You can see the change here: https://android-review.googlesource.com/c/platform/frameworks/support/+/1326201 You may be a little bit confused because

state { someThing }

is a composable call and can only happen inside of a composition, but

mutableStateOf

has no such constraint