Hello. Does it make sense to create a composable t...

# compose

[Berkeli Alashov]

Hello. Does it make sense to create a composable that accepts deconstructed params of viewState? Example in thread 🧵

[Berkeli Alashov]

Is there a difference between doing:

@Composable
fun SomeComponent(
    viewState: ViewState
) {
    SomeComponent1(
        viewState.someProperty1,
    ) {
        SomeComponent2(
            viewState.someProperty2,
            viewState.someProperty3,
        )
        SomeComponent3(viewState.someProperty4)
        Text(text = viewState.someProperty5)
    }
}

vs doing:

@Composable
fun SomeComponent(
    viewState: ViewState
) {
    SomeComponent(
        someProperty1 = viewState.someProperty1,
        someProperty2 = viewState.someProperty2,
        someProperty3 = viewState.someProperty3,
        someProperty4 = viewState.someProperty4,
        someProperty5 = viewState.someProperty5,
    )
}

@Composable
fun SomeComponent(
    someProperty1: SomeType,
    someProperty2: SomeType,
    someProperty3: SomeType,
    someProperty4: SomeType,
    someProperty5: SomeType,
) {
    SomeComponent1(
        someProperty1,
    ) {
        SomeComponent2(
            someProperty2,
            someProperty3,
        )
        SomeComponent3(someProperty4)
        Text(text = someProperty5)
    }
}

[Mark]

In this case, I would use slot API:

@Composable
fun SomeComponent(
    viewState: ViewState
) {
    SomeComponent1(
        someProperty1 = viewState.someProperty1,
        someComponent2 = {
            SomeComponent2(
                viewState.someProperty2,
                viewState.someProperty3,
            )
        },
        someComponent2 = {
            SomeComponent3(viewState.someProperty4)
        },
        someText = {
            Text(text = viewState.someProperty5)
        }
    )
}

@Composable
fun SomeComponent1(
    someProperty1: SomeType,
    someComponent2: @Composable () -> Unit,
    someComponent3: @Composable () -> Unit,
    someText: @Composable () -> Unit,
) {
    SomeComponent1(someProperty1) {
        someComponent2()
        someComponent3()
        someText()
    }
}

[Berkeli Alashov]

Doesn’t make sense since SomeComponent1 will only have one usage in my cases.

But I wonder if my second option is better because viewsState can contain more fields than the component will use (i.e changes in fields that the component isn’t using won’t trigger a recomposition). Or maybe this is already being taken care of by the compiler..

[Mark]

The advantage of slot API approach is that you have single responsibility for the SomeComponent1 composable. That is, to place those three composables within the content of SomeComponent1. Think of the first composable SomeComponent in my example, as having the responsibility to pick apart the ViewState into appropriate entities.
Notice how SomeComponent1 will not change when you add/remove ViewState properties related to SomeComponent2, SomeComponent3 and SomeText.