I would like to optimize this function somehow: it emits a sequence of composables after applying a ...

# compose

[Uli Bubenheimer]

I would like to optimize this function somehow: it emits a sequence of composables after applying a sequence of modifiers:

@Composable
fun ModifiedRow(
    modifier: Modifier,
    columnModifiers: StableImmutableList<Modifier>,
    vararg columns: @Composable (Modifier) -> Unit
) = Row(modifier) {
    val composableIter: Iterator<(Modifier) -> Unit> = columns.iterator()

    columnModifiers.forEach(composableIter.next()::invoke)
}

The Rows are emitted inside a LazyColumn, so I'd like this to be better performing. I want to use this to align header column widths with data column widths.

What I would like to see is inlining all these composables so that they don't get their own recompose scopes, they're all simple lambdas emitting a single Composable each.

I could manually unroll the vararg, since I use this for exactly 15 columns right now, but I'm holding out for something more elegant. I'm guessing that some advanced Compose magic could pull this off (even though it may be overkill compared to the manual unroll approach).

[Leland Richardson [G]]

can you elaborate more on the use case or show what you are doing at the call site? it’s not clear to me what this is adding

[Uli Bubenheimer]

Essentially this, aligning header columns widths with data column widths:

LazyColumn {
    stickyHeader {
        Row {
            Text("A", Modifier.width(10.dp))
            Text("B", Modifier.width(13.dp))
            // ...
            Text("Z"), Modifier.width(7.dp)
        }
    }

    items(pagingItems) {
        Row {
            Image(it.a, Modifier.width(10.dp))
            Text(it.b, Modifier.width(13.dp))
            // ...
            Switch(it.z, Modifier.width(7.dp))
        }
    }
}

[Uli Bubenheimer]

I only want to specify the widths once, and don't want to keep the widths manually aligned, because that's pretty error-prone with a large number of columns (with or without additional constants).

[Leland Richardson [G]]

not sure if this is a silly idea but can you not just define the modifiers above these scopes once and then just use the reference to them in the header/items rows?

[Leland Richardson [G]]

and can you show me how the OP code would be used in the above code?

[Uli Bubenheimer]

That's easy to validate when you have a handful of columns but this kind of approach gets unwieldy with 15 columns, it's hard to verify the correctness, as you still have to reference your 15 modifier variables 30 times, twice each in the correct places

[Uli Bubenheimer]

You also have to define them correctly first, and the definitions are now completely removed from the usage sites

[Leland Richardson [G]]

(to be clear, not saying your idea is unwarranted, just wanting to make sure i understand the problem you are solving)

[Uli Bubenheimer]

I guess I can't get around defining the modifiers separately though. I had filed this feature request to get something that does not have this problem, but it was turned down: https://issuetracker.google.com/issues/200059826

[Uli Bubenheimer]

What I'd really like to have is to define my column widths with my headers, then it's all clean and easy to understand and validate. Everything else just turns into a freakin' mess

[Uli Bubenheimer]

Like I say in that feature request, displaying a data table with equally aligned header & body columns is a standard use case in pretty much all UIs and should be supported by Compose UI. Of course, that's not what you deal with I believe

[Leland Richardson [G]]

i think your use case is a table layout which LazyColumn isn’t really meant to be. i think the best thing would be for someone (you, someone else, google, or whoever) to make a proper table layout composable that would accomodate this use case in the API shape as well as in the guarantees of the layout algorithm, both of which lazy column does not currently do

[Uli Bubenheimer]

Yes, that makes sense. I saw some Lazy-related changes in recent compose alphas where I thought it might possibly go in this direction, but have not looked into it. Probably not, based on the outcome of the feature request.

[Uli Bubenheimer]

Still, I think I can address this a little better with the gist that I posted initially, but would like a better performing version, plus it would be interesting for me to see what Compose magic I might use here.

[Uli Bubenheimer]

I've started unrolling my vararg...

[Uli Bubenheimer]

I guess I could instead use a lookup Map<String, Modifier> for the widths, which would make it easier to validate their correct usage sites.

[Uli Bubenheimer]

But really using constants is better, so I guess that's what I'll do after all.

[Uli Bubenheimer]

Thanks for forcing me to think it through!