Is it possible to seamlessly synchronize compose text changes with an external state objects 'text' property? More details in 🧵

Could your holder internally hold the String in MutableState instead? That would solve external changes not being reflected in the UI, and it would also make edits to it from compose instantly reflect in the state holder

Maybe, but Im having a hard time visualizing how the entire flow would work.. Holder is immutable, in an immutable state. Making it mutable this way would break things, probably.

What would it break? We definitely have some state holders like that, which are marked @Stable and have internal mutable compose State. How does the denouncing play into this here? What is the final thing you want to achieve here? Maybe that'd help me understand

This is the breaking point 😅 Everytime the state changes, a render pass is performed; with mutable properties in state, the states would always be equal (for changes in mutable properties).

if (state != newState) { x }

I'd just update the thing in the holder itself immediately, and if something else needs to do something in reaction to that change with a debounce, you can easily do something like

LaunchedEffect(Unit) {
  snapshotFlow { holder.text }
    .debounce()
    .collect {
      // stuff
    }
}

Problem is that compose is nowhere to be seen around this part of the codebase, so the state comparison is ultimately what decides if a render pass is to be performed (which then gets sent into a MutableStateFlow, that compose renders).

Hmm how far from the compose layer are we talking about? We do have some places in the app where the presenter emits the new states of there are changes. But part of that state is also an object which contains a mutableState reference. So this does in fact mean that when that state changes, it doesn't make the presenter emit a new value, but it just changes it internally so to speak. This works fine, and is more or less required to make BasicTextField (or BasicTextField2) be able to work snappy

Its part of the in-house presenter framework I built way back! So its used both with and without compose, hence no direct integration with it yet (also, time). This means that I need the state to be "changed" for realz, since the render pass needs to happen (also, side effects from the new state need to be aware of the change, etc). Ultimately Im happy with this setup, you know how I rave about its awesomeness 😅 but for this particular case Im not sure theres a golden ticket or win/win scenario, or is there? I guess I could introduce a version parameter on the holder class, which ultimately would be used as the remember key for the mutableStates in compose. Thoughts on that?

Right right then I see why this won’t work. I think your best bet is then in fact to have the state contain normal non-compose mutable state values, and in the composable itself, have a copy as MutableState for the text field to read. Then on each change, you’d have to report that back to your presenter. Will there be situations where the presenter will also want to change that text, or do all changes to it come from the text field itself? If you’d then need the presenter state change to also update that local MutableState copy, you might end up overriding new states that maybe were written really quickly while the presenter was still processing it and so on. Overall it’s never going to be perfect if you can’t hoist the entire state holding object to the model that your presenter is emitting. Which you maybe can’t do here if that presenter needs to support normal views too.

I think we agree? Its just like the version thing I mentioned, without the version 😄 Version would just be there in order for external changes to text to be visible in compose, and I think it would be fair to expect UI elements to "just update" to reflect these changes, even if it happens in the middle of typing (this would be a rare occurence, so I dont expect that to happen a lot, or at all). As for the breakings, thats what I was seeing previously pretty much; regardless if I was using debounce or just updating holder.text and using it for UI. I think this is overall the best solution, just keeping the state in compose as SOT and updating the backing holder on every text change. When holder changes externally, compose SOT is "reset" back to the holders value, and so it goes. From my limited testing, input is super fluid and reflected in holder immediately. Hopefully nothing breaks 🤞🏽 Ill update if anything comes up. I really appreciate the discussion, this ended up working so much better than I initially anticipated!

When holder changes externally, compose SOT is “reset” back to the holders value, and so it goes.

Yeap, as long as you make sure that the state changing from the input itself doesn’t create this loop, then yes it should just work I think 😄 Good luck with it! Always happy to help when I can 😊

> Holder is immutable, in an immutable state. Making it mutable this way would break things, probably. It doesn't have to be immutable, though. It can be

@Stable

as well, with the same performance benefits, and it's what you should be doing anyway if you have mutableStates within it. Dumbed down refresher: immutable is almost the same as stable, except that it says nothing about notifying compose of changes.

You are repeating things 😅

On vacation and haven’t had coffee yet today so a bit slow and struggling to get the gist of the issue. Is it that where your state holder is defined is not allowed to depend on compose-runtime and thus can’t use MutableState?

I think that’s probably the gist of it. Possibly combined with the part that said: “Its part of the in-house presenter framework I built … used both with and without compose … This means that I need the state to be “changed” for realz, since the render pass needs to happen (also, side effects from the new state need to be aware of the change, etc).” so my understanding here is that this framework is relying in some way on state changing in a way that you can do an equal check on it before and after to make sure they are actually different. Which prevents the usage of internally mutating state in the first place.

I really wish I liked coffee. I dont know if I have anything of value to add to this discussion 😛 The approach we spoke about earlier seems to work perfectly well; even with debug builds performance is pretty much flawless despite the entire state being emitted for every letter typed (the resulting state that gets displayed is stable).

Did you go with the explicit version number or not?

With BasicTextField2 won’t this be even more tricky to pull off in this way with 2 sources of truth?

Shouldn’t be

I have done this somewhat hackily over network 😅

Yes, version number! Good to know that you did something similar, it's just something that came to mind spontaneously during our discussion earlier. Practically I'm doing remember(version) { mutableState(holder.text) } whereas earlier I was specifying holder.text as the key. I can imagine that basic text field 2 would work the same way.

I really wish I liked coffee

Same! We probably have that gene that makes this and coriander etc taste far more bitter than normal.

Careful what you wish for. I’m just a lost cause - I’ve been drinking coffee since I was like 5 years old, which is probably why I have so much anxiety 😅

Definitely need some more anxienty in my life 🤝🏽