A modern programming language that makes developers happier.

kotlinlang

Latest version of Compose removed the `String, (String) -&gt; Unit` overload of BTF2, leaving only the one with `TextFieldState`. Does this mean that Compose enforces us to hoist the `TextFieldState` directly inside the ViewModel state, because including the suggested workaround with `StateSyncingModifier` and etc. into each project is too cumbersome? I'm used to think that including any compose-related class (`MutableState`, `TextFieldState` or anything else) into my ViewModel is a bad practice (and sometimes even impossible). Or is there some better option?

&gt; StateSyncingModifier
What’s `StateSyncingModifier` from here? Is that from some blogpost, or something in the library that is new?

&gt; I’m used to think that including any compose-related class (`MutableState`, `TextFieldState` or anything else) into my ViewModel is a bad practice
Hoisting your compose related classes into ViewModel is by no means a bad practice. The non UI parts of compose can just be used there without any problem. The one problem which I can imagine is if you are sharing your ViewModel with iOS and having a TextFieldState in it might not be possible, that I can understand.

I've seen this Modifier in a commit which removed the overload and added this new sample: <https://android-review.googlesource.com/c/platform/frameworks/support/+/2966770/4/compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/BasicTextFieldValueSample.kt|https://android-review.googlesource.com/c/platform/frameworks/support/+/2966770/4/compose/fo[…]mpose/foundation/samples/BasicTextFieldValueSample.kt>

This part of this cl
```It's also possible to internally wrap around an existing TextFieldState and expose a more
lightweight state hoisting mechanism through a value that dictates the content of the TextField
and an onValueChange callback that communicates the changes to this value.
@sample androidx.compose.foundation.samples.BasicTextFieldWithValueOnValueChangeSample```
Seems to want you to look at this <https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/BasicTextFieldValueSample.kt;l=41?q=BasicTextFieldWithValueOnValueChangeSample&amp;sq=|https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]mple.kt;l=41?q=BasicTextFieldWithValueOnValueChangeSample&amp;sq=> and just copy-paste that if you want to have a BTF2 with the old API.

You say that it sounds cumbersome, but you only import it once and it should be fine from that point on, no?

With that said, is the limitation that you can’t hoist your TFS to your VM that you are sharing it with an iOS client?

There is no limitation I think, it's just a thing of code architecture and correctness. I was under impression that hoisting Compose in ViewModel is bad even in pure-Android projects, but if it's not, then there's no problem!

Many of our ViewModels are literally entirely written in compose (not compose UI) with <https://github.com/cashapp/molecule|molecule>.
Definitely not a bad thing to do :smile: