Hey :wave: I would like some advice regarding sca...

# compose

[Lucas Villa Verde]

Hey 👋 I would like some advice regarding scalability of UDF pattern in composables. Currently we have a screen that contains 20+ One-off events and 10+ activity launchers. How do you usually abstract/scale that to avoid compromising readability and making the composable method convoluted?
Rearchitecturing the ViewModel or refactoring the whole screen pattern is not an option at this moment. I would like to focus on this specific case:

val cameraPermissionLauncher = rememberLauncherForActivityResult(
        contract = ActivityResultContracts.RequestPermission(),
        // Define the callback that sends the result back as an Action to the ViewModel
        onResult = { isGranted ->
            viewModel.onAction(MyScreenAction.PermissionResult(isGranted))
        }
    )
    // ... +10 rememberLauncherForActivityResult (but it could be another screen handler as well non android specific)

    LaunchedEffect(key1 = Unit) {
        viewModel.events.collect { event ->
            when (event) {
                is MyScreenEvent.ShowToast -> {
                    snackbarHostState.showSnackbar(event.message)
                }
                MyScreenEvent.NavigateToNextScreen -> {
                    onNavigate()
                }
        // ... +20 other events

[Winson Chiu]

You have 10+ other launchers in the top level composable? I would expect you to move those to the child composables which actually start the launcher, closer to the button.

For the events, the official recommendation in the docs is to not use UI events, but instead toggle a state value, requiring the UI to check and un-toggle that state before acting on the event. This shoves the handling of UI effects down into the child composables as well, since your top level state object would contain smaller state classes, one for each functionality block in your children.

Doing both of these would remove most of this from this large top level.