👋 Is there a better way to "inherit" from a Composable than redeclaring all the parameters of the inherited? I want to extend the functionality of some Material composables with custom logic that I don't want to repeat everywhere.

I guess you could always declare an interface for the Composable?

🤔 I can’t see the use case of it. How would I then make the call to the Material composable? I’m talking not having to redeclare all parameters in something like:

@Composable
fun MyTextField(
    val value: String,
    val onValueChange,
    ...
) {
    TextField(
        value = value,
        ...
    )
}

The design pattern that Compose uses it „Composition over inheritance“. That’s why Composables are functions and not classes. So the answer to your question: yes, you have to redeclare all parameters that your custom Composable uses.

Ok! That’s what I was expecting, but maybe you pros had a cool Kotlin-ized way to do it 🙂. Thanks!

I guess this is an opportunity for a plug-in that auto generates the parameters you have to redeclare with appropriate default values (or am I being too lazy?)

It’d be really good, to be honest.

Good luck with binary compatibility though.

@Zun there's a proposal somewhere to create a

dataarg

modifier that adds all the parameters of a data class' constructor to that function if you really want to make a plugin, that essentially solves this problem and can be useful in many other places as well

I don’t completely agree about it being that rare. When building a design system it’s quite normal to wrap up (it was inheritance before) a base Composable exposing everything but adding some logic and even extra parameters. Maybe you won’t expose all its parameters, but a good amount of them.

If you don't expose all of them, though, then the solution that copies all of them (eg via a plugin) is not useful to you.

Sounds like the most straightforward solution, yes. Thanks, man!