I have a composable "*Item*" that accepts a `trail...

# compose

[Zoltan Demant]

I have a composable "*Item*" that accepts a trailing: @Composable (() -> Unit)? and a bunch of configuration parameters for it (trailingInset: Dp, etc). Its quite similar to ListItem in M3 in that it structures content and provides styling for it.

It works great! Say I have a composable "*Transaction*" that starts out just using Item internally, and a week later I want to add some dynamic trailing content to it. Similar to what Item does, Id add trailing: @Composable (() -> Unit)? to this composable, and it would work.

Over time, my composables become bloated.. because over time almost every composable like Transaction, will want to at least support a trailing composable, and its corresponding configuration parameters.

Afaik, theres no perfect solution to it. What would you do? Some experimental thinking in 🧵

[Zoltan Demant]

Just straight up API awareness: I dont think anything (currently) can beat just having all the configuration parameters as function arguments. It just gets very boilerplately.

Super_solution_9000: Having something akin to LazyListScope, and a configure: ItemScope.() -> Unit block, I would still need to add this to every one of my composables using item if they want the added flexibility.. but it would be one parameter, and it would have stuff like fun trailing(block: @Composable () -> Unit).

So yeah, these are the 2 extremes from my point of view. I know that Im not a big fan of the raw path. It works when theres just a few composables involved, but were talking about roughly 50 for my case.

[Brill]

I deal with this my making containers and composite components. Start with the smallest useable component. Make it light and keep it focused (think SoC in design mode), eventually you will start putting into together into a larger component, which you can also keep simple.