Hi folks :wave: Is there a way to only allow certa...

# compose-android

[Shivam Verma]

Hi folks 👋 Is there a way to only allow certain composables in case of a slot based api for a composable ? Ideally, I would like to restrict a composable to only accept x, y, z other composables gratitude thank you

[Pablichjenkov]

Declare a State class/interface and accept only Composables that are extension of this class.
Is the only thing that comes to my mind.

@Composable fun(
  content: @Composable AllowedStateOnly.() -> Unit
)

Another possibility is the classic interface:

interface AllowedStateOnly {
  @Composable fun Content(modifier: Modifier)
}

[efemoney]

Compose falls very flat in the face of this simple requirement.

The ONLY solution is to write a custom Layout and reimplement even basic measure/layout logic like box, row & column.

Depending on your use case it might not be worth it tho.

[dorche]

Not the only solution really.

It's not pretty but you could make N wrappers around the composable with the slot API and make the original one private.

[efemoney]

No you couldn’t. Because the moment you have a slot anyone could put anything there. If you dont have a slot then its not a slot API anymore.

[Shivam Verma]

Somewhat related to @Pablichjenkov’s suggestion is this approach. Given that there is no straightforward solution, I guess the question to answer here is how important is this validation when building slot based apis.

[efemoney]

The solution should be for Compose to add APIs for this. Point blank.

@Shivam Verma That approach will compose the content twice: so double memory usage, less performance since composition is one of the more expensive phases. Also if you add that in a row or column with spaced arrangement, it’ll add the spacing twice for each node because that actually adds a node even if its with zero size

Thats a non-starter imo 😞

[efemoney]

Would be better if there is an API to conditionally emit a layout node.

[Shivam Verma]

thanks for your input folks! 🙏

[efemoney]

Maybe the compose folks can chime in. I thought that the composable marker annotations (@UiComposable, @VectorComposable etc) were supposed to be some sort of solution for this.

But I dont know how they work tbh

[Pablichjenkov]

If you open a slot it will basically be impossible to control what the client paints in it.
Don't know your use case but an option perhaps is not exposing a slot but a StateInterface. And you painted your way once the pass the implementation.