Thread
#compose
    Nacho Ruiz Martin

    Nacho Ruiz Martin

    1 year ago
    👋 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.
    c

    CLOVIS

    1 year ago
    I guess you could always declare an interface for the Composable?
    Something like
    interface MyComposable : @Composable (Int, Int, String) -> Unit
    Not 100% sure that works
    Nacho Ruiz Martin

    Nacho Ruiz Martin

    1 year ago
    🤔 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,
            ...
        )
    }
    Chrimaeon

    Chrimaeon

    1 year ago
    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.
    Nacho Ruiz Martin

    Nacho Ruiz Martin

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

    Zun

    1 year ago
    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?)
    Nacho Ruiz Martin

    Nacho Ruiz Martin

    1 year ago
    It’d be really good, to be honest.
    Dominaezzz

    Dominaezzz

    1 year ago
    Good luck with binary compatibility though.
    c

    CLOVIS

    1 year ago
    @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
    The ‘real’ Compose answer though is probably something like ‘it should be fairly rare that a Composable wraps another one and exposes all its children, so that problem should be rare enough that it's not really an issue’?
    Nacho Ruiz Martin

    Nacho Ruiz Martin

    1 year ago
    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.
    c

    CLOVIS

    1 year ago
    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.
    I think the best way is just to copy all you need, and have global/companion default values (so you don't have magical default values everywhere)
    Nacho Ruiz Martin

    Nacho Ruiz Martin

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