Thread
#compose
    Anastasia Rozovskaya

    Anastasia Rozovskaya

    1 year ago
    Hello! What is your attitude to compose functions, wrapped into class/object? The reason behind this question states like this - “when you start typing name of some object, first things AS proposes you is compose functions even in scopes related to domain/data layers”.
    b

    Brian G

    1 year ago
    If you don't want your UI-layer code to be suggested when editing your domain/data-layer code, you could put them in separate modules. E.g. put your domain/data-layer in commonMain using kotlin multiplatform. Or, put it in a separate gradle project.
    Adam Powell

    Adam Powell

    1 year ago
    I'd avoid it, personally. We had a lot of discussion around using objects as namespaces for composables and decided to stick to the top level. It adds noise at usage sites that impacts readability, and
    object
    invites private state in the form of "constants" in those objects that can't be declared
    const
    . If the types of those objects aren't inferred as stable, then the
    object
    itself isn't stable.
    object
    methods still receive the
    object
    as
    this
    using all of the normal rules of parameters, and if
    this
    isn't stable, the composable isn't eligible for skipping, affecting performance.
    making a convention out of declaring your composables on objects means you're in this series of overlapping edge cases all the time, and imo the hassles it introduces aren't worth the potential advantages of tidying top-level autocomplete. Kotlin as a language embraces the top level and so does compose.
    Anastasia Rozovskaya

    Anastasia Rozovskaya

    1 year ago
    Adam, I quite agree. Thanks for sharing your opinion. Brian, the composables are already in a separate Gradle project, but when I need them I include this project in other Gradle projects (other modules) and composables become visible as they should. The idea to extract data/domain layers completely is also tempting, although it's not a part of our architecture. But anyway, thanks for sharing too.
    b

    Brian G

    1 year ago
    You're welcome 🙂 If you're curious about that architecture, you can read more about it here: https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/