Hi guys, i have a screen like ```@Composable fun M...

# compose-android

[brabo-hi]

Hi guys, i have a screen like

@Composable
fun MyComponent(uiState: MyUiState, firstName: String, lastName: String) {
  Column {
        Text(text = uiState.data)
        TextField(value = firstName, onValueChange = {})
        TextField(value = lastName, onValueChange = {})
    }
}

Where MyUiState is represented into the viewmodel as StateFlow
firstName and lastName as State used both in TextField. Is it a good practice to add firstName and lastName into the StateFlow MyUiStateFlow?

[Christiano]

From what I understood, the uiState should contain everything that the UI will show.
Also working with events, makes it a lot easier to manage and update the state in the viewmodel.

[brabo-hi]

from this https://medium.com/androiddevelopers/effective-state-management-for-textfield-in-compose-d6e5b070fbe5
it looks like it is not recommended

[Christiano]

Ah wow, didn't run into an issue like that before, but nice to know that for text fields it is not the recommended way! Thanks for the tip Brabo-hi 😄

[dewildte]

Love that blog post.

[Colton Idle]

Unpopular opinion (seemingly):
My state classes always just look like

class MyState{
val firstName by mutableStateOf("")
val lastName by mutableStateOf("")
...
like 10 other properties
}

I never have any issues. shipped 5 apps to prod (with millions of users and better than 99%+ crash free sessions). dont really use Flows for state. /shruggie

[Stylianos Gakis]

How does your typical ViewModel look like in this case Colton?

[Colton Idle]

Not sure if this is what you're asking about. but like 95% of my VMs look something like this

[Colton Idle]

class MyVM(appState: AppStateHolder): ViewModel(){
val screenState = ScreenState()
fun doX(){
   scope.launch{
    val result = doNetworkCallOrSomething
    screenState.foo = result.mapToDomainOrUiLayer
  }
}
}

[Colton Idle]

of course, I might have a UseCase or repository that might have some flow of data that I'm observing. but a lot of times i just stick with snapshot state for a lot of the simple stuff. So I don't necessarily expose a single big flowable state. but my state might have like 8 snapshot states and 2 flowables.

[dewildte]

I would go the opposite route and pass the ViewModel into the screen state holder.

[dewildte]

Google docs suggest that way of doing.

[Christiano]

I'm not sure if this is what you mean, but by passing the viewModel to a screen composable breaks the possibility for any preview to render.

If you rely on previews (like me) this is not what you might want to do 😄

[Colton Idle]

@dewildte are you talking to me, or the OP?

[dewildte]

You lol

[dewildte]

But it applies to both I guess.

[dewildte]

Sorry I miss read the documentation.

[Colton Idle]

🙏

[dewildte]

The docs suggest passing your business state into your UI state.

[dewildte]

There can be two state holders, one for pure UI level stuff that should not be persisted pass screen destruction. And one for business state that often needs to survive screen destruction.

[dewildte]

I am digressing though.

[dorche]

@Colton Idle the possible gotcha with your approach is making sure you don't do "unnecessary work" - the lifecycle aware flow collection APIs help with that usually.

[Colton Idle]

not sure i follow. but yeah I dont use too many flows and so i dont really have any long running collections.