I have some Composable accepting an icon and I wan...

# compose

[Jan Skrasek]

I have some Composable accepting an icon and I wanna be more strict about the accepted type.

What is the proper way?
• Painter - seems to have mutability issues and I didn't found any copy/clone method.
• @Composable () -> Unit - for custom rendering icon is too benevolent for me
• @Composable () -> Painter - is what I'm ended up. Is it the correct solution?

[Halil Ozercan]

I have 2 questions in return. What is benevolent about regular composable slot? I understand this enables passing of any composable, even one that doesn't emit layout but you strictly want icon.

Then, what is the difference between first and third option? Your composable is going to be called from a Composable context anyway, why do you want to delegate the Painter calculation to another composable. This can be done on the call site.

Imo, slot API is not so benevolent. Ofc it again depends on your overall design decisions, users, and etc.

[Zoltan Demant]

I think the easiest solution is to use a slot API.

However, in a project Im working on we have a design system and wanted to limit the inputs to icons that we have chosen, but allow flexibility to extend it in the future (e.g. Painter support).

We did this by declaring a sealed interface "IconResource"; a subclass of it is an enum with pointers to things like Icons.Rounded.Check etc. It has worked really well, and kept our icons streamlined across a pretty large project (~200 modules); the check icon is always rounded, and we can easily switch that out if need be.

We thought we would rely on Painter for something, but we havent yet. Adding it in would be as easy as declaring another subclass of the sealed interface though. In the icon composable we just derive the icon contents from the subclass specified!