Hi, Just wondering if this code is okay to do? ```@Composable fun doSomething(): State<String> { ...

# compose

[Archie]

Hi, Just wondering if this code is okay to do?

@Composable
fun doSomething(): State<String> {
   val (state, setState) = remember { mutableStateOf("") }
   ...
   // do something with state like for example 
   setState("Helo")
   
   ...
   return state
}

[Archie]

the idea is so that when I need call and do something, I can just do this:

@Composable
fun CallSite() {
   val state by doSomething()

   Text(state)
}

Is this okay?

[Archie]

Another option I could take is to pass in a function instead like so:

@Composable
fun doSomething(onStateChange: (String) -> Unit) {
   ...
   // do something with state like for example 
   onStateChange("Helo")
   ...
}

and so I’d be calling the it like this:

@Composable
fun CallSite() {
   var state by remember { mutableStateOf("") }
   doSomething { state = it }
   Text(state)
}

But I feel like the first approach is cleaner? Thoughts?

[stantronic]

both examples seem to have side-effects without using any of the side-effect apis, so I would recommend to avoid it. Also doesnt look very idiomatic, so other developers might be confused.

[stantronic]

Untitled.kt

Untitled.kt

[stantronic]

Or there is the SideEffect api which might do what you're looking for: https://developer.android.com/develop/ui/compose/side-effects#sideeffect-publish

[Chrimaeon]

@stantronic where do you see “side-effects”? it changes a state and that is reflected in the retuned value. 🤔

[Chrimaeon]

@Archie I think the first approach is the more idiomatic way of handling State.

[Archie]

Sorry for the confusion @stantronic. In the example, the side effect calls are assumed to be called from a button click or inside a side effect launchers.

[Chrimaeon]

the only thing from an architetcural point of view - I’d but that function in a view model to encapsualte business logic from ui logic.

[Archie]

Thanks @Chrimaeon. In this case the I didnt want to move the logic to a ViewModel as everything are view related and was very simple that it doesn't have much logic.

[Chrimaeon]

😅 if you change that state you obviously have some business logic otherwise the whole function does not make sense. or do you just want to extract the same “logic” to be uses in several places?

[Stylianos Gakis]

You may be looking for the "UI state holder" style, used quite a lot in many components. Like this https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/input/TextFieldState.kt;l=637?q=rememberTextField for example.
Or https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/ScrollableState.kt;l=160?q=rememberScroll&sq= etc

Looks ok to me if it's ui logic

[Stylianos Gakis]

https://developer.android.com/topic/architecture/ui-layer/stateholders#ui-logic

[Archie]

In this case, the value is being taken from a library that is launched from a SideEffect, something like:

@Composable
fun Something(): State<...> {
fun Something(): State<...> {
    val state = remember { mutableStateOf() }
    LaunchedEffect {
        LibraryCallThatOutputMultiplrValuesOvertime
        LibraryCallThatOutputMultiplrValuesOvertime
             .addListener { state.value = it }
     }
     }
    return state
}

So in this case I just want to display the value being outputed by the library.

[Stylianos Gakis]

Another example if you want some non androidx example too https://github.com/mxalbert1996/Zoomable/blob/main/zoomable%2Fsrc%2FcommonMain%2Fkotlin%2Fcom%2Fmxalbert%2Fzoomable%2FZoomableState.kt

[Archie]

Thanks @Stylianos Gakis. This is good to know.

[Chrimaeon]

yeah, definitely something I’d put in a view model. your Composable should not know anything about that “LibraryCallThatOutputMultiplrValuesOvertime”

[Archie]

Thanks @Chrimaeon. Might be right to do so. I'll review what I have. Thank you very much.

[Stylianos Gakis]

Since I'm doing this already, here's one which is quite more complex too, to show that this type of pattern can do quite a lot than most people realize 😀
https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:activity/activity-compose/src/main/java/androidx/activity/compose/ActivityResultRegistry.kt;l=80?q=rememberLauncher

[Stylianos Gakis]

But I suppose it depends on what that value is that is emitted onal a flow overtime. If it's business logic and not something UI related then yeah sounds like a VM responsibility to me too.

[Archie]

Aha! I didnt even realized that. Thanks. I got the same idea working on a React Native Project where this pattern is very commonly used as well.

[Archie]

The library could be anything say a location listener. In my opinion in that case, my view model dont need to launch the library, delegate it to the view and simply receive the values produced.

[Archie]

Thank @Stylianos Gakis really appreciate it.