Hello! What is your attitude to compose functions,...

# compose

[Anastasia Rozovskaya]

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”.

[Brian G]

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]

I'd avoid it, personally. We had a lot of discussion around using `object`s 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.

[Adam Powell]

making a convention out of declaring your composables on `object`s 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]

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.

[Brian G]

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/