I was wondering, with the way a lot of components ...

# compose-android

[zt]

I was wondering, with the way a lot of components have states that are instantiated by using their respective rememberXState method, should I also follow this pattern? My existing method was just passing the viewmodel to the composables, or having everything explicitly as a parameter which isn't very elegant

How can I determine which to use?

[Rohan Maity]

What is wrong with viewmodel approach or separate variable approach?

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

It really depends

[Stylianos Gakis]

There’s a lot of super nice documentation about thinking in compose and all the good things you get from state down - events up. An equally in-depth document from google would do wonders! This has been a very popular piece of discussion lately as I see it. Especially with BasicTextField2 doing exactly this, and other components like DatePicker from material3 going stable now and more people start using it and talking about it - see: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1684488623413739

That, paired with a code-lab and this entire google doc package would be amazing to have on this topic imo. When such official sources exist, these discussions are much easier to have, as we can always refer to those for some guidance.

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

The decision whether to have a single class grouping all your inputs or separate params, whether to provide some sort of hoisted state holder (and what goes in it), and whether to write a remember wrapper for it, are really three separate decisions.

Single-class vs multi-param is often a matter of what inputs you expect to be changed together vs independently.

Providing a hoisted state holder vs callbacks to modify state usually depends on whether you want the state to be modified imperatively outside the composition (eg as with ScrollState and FocusRequester), or if you need to be opinionated about how the state is actually stored (as with BTF2 that Stylianos mentioned).

A remember wrapper is typically used to pass a Saver implementation to rememberSaveable, or if your state is complex enough to require reading composition locals. If you’re not doing that, it’s typically better to just provide a constructor or non-composable factory function (which you should typically do if possible anyway to allow callers to wrap your state in their own holders).