Reading this topic regarding Compose+ViewModel… Im...

# compose

[nglauber]

Reading this topic regarding Compose+ViewModel… Imagine that my screen has 10 TextField … which one would be better: 1) expose a series of LiveData/StateFlow; or 2) encapsulate in a object and every change send a copy of the object just changing one property? (I mean myObj.copy(fieldThatChanged=newValue))
https://developer.android.com/jetpack/compose/state#viewmodel-state

[Colton Idle]

If you don't have to use LiveData or StateFlow (which for just showing text fields on the screen, you do not) you can just use snapshot state (i.e. mutableStateOf)

From what I have learned recently, I would simply do this via

class MyViewModel : ViewModel() {
    val state = MyViewState()
...
}
class MyViewState {
    var textField1 by mutableStateOf("")
    var textField2 by mutableStateOf("")
    var textField3 by mutableStateOf("")
    // etc
}

Since you're not consuming an observable from some other source, you get to use all of the primitives that compose gives you out of the box. Even if you wanted to use LD or SF you would still need to call the function to convert it to snapshot state, so you just saved yourself some resources.

Other pros of this is no backing property syntax, no livedata.value!! stuff, and setting values is super easy. You never have to call copy. You just set the value.

Adam Powell can correct me if I'm wrong, but using snapshot state gives you the immutability that you're probably used to, but you interface with it as if it was mutable. Win win.

[nglauber]

I understand your point, but I don’t want to tie my ViewModel to Compose…

[nglauber]

I’m also hoisting my callbacks to the ViewModel, which allows me to validate the data in the ViewModel as well…

[Colton Idle]

I understand your point, but I don’t want to tie my ViewModel to Compose… (edited)

🤔
In a pure compose app you don't need to use AAC VMs, but at the end of the day... you have to "tie" together your AAC VM (or plain old VM/state class) to your activity/fragment/composable.

I’m also hoisting my callbacks to the ViewModel, which allows me to validate the data in the ViewModel as well…

Everything I mentioned above works with what you want to do. Just write your onChange1, onChange2, etc methods and you're on your way.

[nglauber]

I would like to know about this: “In a pure compose app you don’t need to use AAC VMs” (at least it was what I understood)…
Wouldn’t AAC VMs still useful to keep data across config changes?
I saw a discussion on twitter by @Ian Lake and @cb not sure if it’s related…
https://twitter.com/ianhlake/status/1395150555337478145
But I really would like to take a look in some “Good practices using Compose in MVVM” article/post/docs/video

[Ian Lake]

Compose, in and of itself, is a reactive model. As long as your state is driving your UI, that's as opinionated as Compose itself needs to get. That's why #compose-desktop and #compose-web and Compose for command line (https://github.com/JakeWharton/mosaic) all work: the fundamentals of delivering changes to your UI and recomposing it in response are purposefully generic

[Ian Lake]

There are best practices for using Jetpack libraries with Compose that explains those best practices for using those layers on top with Compose, specifically targeting problems and situations you face on Android:

https://www.youtube.com/watch?v=0z_dwBGQQWQ▾

[Ian Lake]

If you're using those layers together, they work great together and give you a lot by default out of the box

[Ian Lake]

But every one of those integrations in based on the same fundamental building blocks that let you go build your own infrastructure that exactly fills your needs (which also means you have to know every edge case and understand how to handle each one or know enough about the system to say 'this edge case doesn't matter to me because of X and Y, but if either of those change, I will need to take on the work myself to change my solution to handle that edge case')

[Ian Lake]

That's great and that's working as intended

[Ian Lake]

Compose is smart enough to figure out 1 LiveData, 5 StateFlows, or 10 MutableStates, so just use whatever fits your architecture best

[Tash]

That video was great! Learnt a ton. Love how Android dev is almost unrecognizable with all the Jetpack libraries working in tandem; love it! 🙌🏼

[nglauber]

Thanks @Ian Lake! This video is exactly what I need 👍

[Neal Sanche]

What I specifically like about the video is the focus on keeping composables data driven, and showing ways to use AAC ViewModels as part of navigation, and keep the composables cleaner. It's a simple thing that I hadn't even thought of, that stems from the data down, events up mentality I think we're all probably getting used to still.

[Tash]

Takes me back to this great insight from Jim
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1614363459453500?thread_ts=1614353787.418800&cid=CJLTWPH7S