I’ve an idea. What if every composable function re...

# compose

[rsktash]

I’ve an idea. What if every composable function returns virtual custom Unit void in order to restrict composable function content types. We could convert these custom units to void at compile time.

For example: We have a composable function which accepts only Text composable
@Cooposable
fun RenderSomeUI(modifier: Modifier, content: @Composable () -> TextUnit){
}

[rsktash]

@jim

[jim]

@rsktash

That would start baking some very strange rules into the language, as return types don't normally behave that way. A much better option (which you could implement in user land yourself, if you felt so inclined) would be to add your own annotation which specified the required content type. For example: @Composable @ContentType("Text") ()->Unit or @Composable @TextType ()->Unit as these are annotations and you can have your own annotation checkers to verify them. Nothing stops you from building this on top of Compose, hence it doesn't need to be a part of the Compose core.

However, more to the point, it isn't clear that such restrictions are beneficial. We believe that Compose should not take a privileged position, meaning that if we can implement a Text() widget, you should just as easily be able to implement such a MyFancyText() widget which is otherwise interchangable. If the content of Composables were restricted, that violates the fundamental philosophy of nothing we do being privileged, because now you must use our widgets if you want to be interoperable with other widgets.

If the container widget needs to make assumptions about properties of the content (like it being only text), you're better off just having your widget accept a string and directly control its children. That way, you don't need to worry about the endless permutations of things that a user could do to break your assumptions (a text widget with padding, or a crazy font size, or whatever else a user might try).

[rsktash]

Ok then why not to annotate these base composables with @TextContent @IconContent @ImageContent ?

[jim]

Yeah, if it would be sufficiently valuable to the community, we could probably accept such a change. I think it just hasn't yet proven its value. Like I mentioned, in most cases where you would want the content to be only Text for instance, it implies you are using that constraint as a proxy for some underlying constraint that you are trying to enforce, and most likely your proxy isn't actually enforcing the constraint you think it is (because of things like padding, font size, etc).

[Anton Popov]

Related problem

[rsktash]

@jim I tried with annotation but I couldn't restrict maybe it's IDE related issue. Android studio is ignoring it

[jim]

I'm not sure what you mean, you didn't give enough context here, like what mechanism you are using to enforce your custom annotations?

[jim]

There are several options, the one I'm most familiar with is writing your own Kotlin compiler extension point, but you could probably use something like kapt or lint or other tools to enforce. Regardless of how you do it, yes, it is going to take some work to integrate into your toolchain. Getting command line enforcement would be your first step though, and then figure out how to integrate into the IDE later.

[rsktash]

Thank you

[Javier]

Is it not possible with extension fun?

[Colton Idle]

I've had cases where I want to restrict a composable to only take in a Text composable... what I did was create a composable that only takes in a String, and then I put it in the Text composable myself.

The Text composable becomes an implementation detail and I'm free to update it to whatever in the future, and I don't have to mess around with trying to only allow certain Types in it's "slot" api like you have.