If I have a form with around 7+ fields Should i ha...

# compose

[Vaibhav Jaiswal]

If I have a form with around 7+ fields
Should i have a mutableState for each field or should i keep app fields in a data class and just have one mutableState ?
Which one is a better approach to follow?

[Stylianos Gakis]

I actually did something similar the other day, and I did enjoy having a separate mutableState for each of the fields.
This is especially true for fields that are using custom state holding classes, like the new BasicTextField which requires TextFieldState, or if you got date picking fields so you are using DatePickerState etc. which you wouldn't be able to put inside a data class anyway.
You could either have one big state holding object, which will internally have mutable states internally, or just have them all separate fields without them being combined under one bigger umbrella.

[Vaibhav Jaiswal]

I'm planning to later migrate to the new TextFieldState when material3 upgrades to new BasicTextField internally

So, i guess keeping separate fields will be better

[Stylianos Gakis]

Yeah you can give that a try.
You should always keep in mind that you can also do a combination of this, as described here https://developer.android.com/topic/architecture/ui-layer/stateholders#dependencies
So passing in those states inside your own all encompassing state holder that has everything inside it

[Zach Klippenstein (he/him) [MOD]]

It's really up to you. Using a single large object could recompose some things more than necessary depending on how your data is structured, but not in a way that would be significant to performance.

[Erfannj En]

@Zach Klippenstein (he/him) [MOD]
What is your recommended way to form validation?

[Zach Klippenstein (he/him) [MOD]]

I don’t have any opinion myself, and I’m not aware of any official guidance on form validation

[agrosner]

A form data class object is my go to. Keeps state snapshots. Even better if you can use a selector function in more specific spots where you only need one thing

val name by viewmodel.select { it.name }
Where select returns a compose derived state

[agrosner]

A mutation could happen. Like:
viewmodel.mutate { copy(name = newName) }