Hey people, have a question about sealed interface...

# compose

[Maciej S]

Hey people, have a question about sealed interfaces and stability/skippability 🧵

[Maciej S]

Given I have a model like

sealed interface AvatarUiModel {
    data class ParticipantInitial(val value: String) : AvatarUiModel
    object DraftIcon : AvatarUiModel
}

And a composable that takes this type as a param, like

@Composable
fun Avatar(
    modifier: Modifier = Modifier,
    avatarUiModel: AvatarUiModel
) {
...

that is a part of lazy column’s item composable, I can see in the layout inspector’s recomposition counts that the Avatar composable is being recomposed all the time while scrolling through the list. This is not the case if I simply use a sealed class, like

sealed class AvatarUiModel {
    data class ParticipantInitial(val value: String) : AvatarUiModel()
    object DraftIcon : AvatarUiModel()
}

If I do that, I can see that the Avatar recompositions are being skipped while scrolling, as expected.

The compose compiler report marks the Avatar composable as skippable when using the interface, however, the param is not marked as stable (see the attached screenshot).

Is that behaviour expected?

[Zach Klippenstein (he/him) [MOD]]

Good question – @Leland Richardson [G]?

[Leland Richardson [G]]

its skippable because the avataruimodel is runtime stability (versus known stable or known unstable) what does the callsite look like? i am not 100% sure what we do here, I should add a test case for it

[Maciej S]

Thanks for taking a look, here’s how we use the Avatar composable:

@OptIn(ExperimentalFoundationApi::class)
@Composable
fun MailboxItem(
    modifier: Modifier = Modifier,
    item: MailboxItemUiModel,
    onItemClicked: (MailboxItemUiModel) -> Unit,
    onOpenSelectionMode: () -> Unit
) {
    Box(
        modifier = ...
    ) {

        MailboxItemLayout(
            avatar = { Avatar(avatarUiModel = item.avatar) },
            ...
        )
    }
}

and the MailboxItem is called from a lazy column:

@Composable
@OptIn(ExperimentalFoundationApi::class)
private fun MailboxItemsList(
    listState: LazyListState,
    items: LazyPagingItems<MailboxItemUiModel>,
    actions: MailboxScreen.Actions
) {
    LazyColumn(
        state = listState,
        modifier = ...
    ) {
        items(
            items = items,
            key = { it.id }
        ) { item ->
            item?.let {
                MailboxItem(
                    modifier = Modifier.animateItemPlacement(),
                    item = item,
                    onItemClicked = actions.onNavigateToMailboxItem,
                    onOpenSelectionMode = actions.onOpenSelectionMode
                )
            }
        }
    }
}

[Leland Richardson [G]]

i believe in this case we don't currently know what the stability of the thing returned by item.avatar is, so it ends up being "unstable". Theoretically we could do better here because we could infer a sealed interface as being always stable if we know that all of its implementations are always stable. We don't currently do that but it is a good idea

[Maciej S]

Thanks for the explanation! Perhaps it would be worth adding this information to one of those ‘performance tips’ types of articles/videos out there which touch on making the types stable/avoiding recompositions? I imagine we are not the only ones making the assumption that sealed classes and sealed interfaces would be equivalent in terms of stability.

[Leland Richardson [G]]

it's a reasonable question, but not a clear answer. these types of "tips" or "rules" have a habit of living longer than the problem they are helping workaround. I would rather we create a bug for this and just fix it than have it spelled out in a document as a tip somewhere

[Maciej S]

Fair point, sounds good 👍

[Maciej S]

Hey, coming back to this: do you already have an issue for this on your side that we could track or should I add one?