Is it a bad idea to define a class contianing Comp...

# compose

[Archie]

Is it a bad idea to define a class contianing Composable functions to impose a type dependency?

[Archie]

UseCase:
We have 3 apps. All must look the same except for a few specific branding items.

[Archie]

For example:
Title could be an image for 1 app while the other two apps could simple be using Text.

[Archie]

We thought of moving all our common logic/composable inside a common module which would be a dependency of the each of the 3 app module.

[Archie]

In our common module we define the Screen:

GenericScreen(
   ...
   title: @Composable () -> Unit, // a composable function to make it flexible
   ...
)

[Archie]

In our common module we also want to define our NavGraph as all the app should also have the same navigation.

fun GenericNavGraph(
   ...
   title: @Composable () -> Unit,
) {
   NavGraph(
      ...
   ) {
      composable("route") {
         GenericScreen(
            ...
            title = title
            ...
         )
      }
   }
}

[Archie]

The above approach works fine but it starts to get bloated.

fun GenericNavGraph(
   ...
   title: @Composable () -> Unit,
   anotherBranding: @Composable () -> Unit,
   anotherOne: @Composable () -> Unit,
   nextOne: @Composable () -> Unit,
   ...
) {
   NavGraph(
      ...
   ) {
      composable("route") {
         GenericScreen(
            ...
            title = title
            ...
         )
      }
   }
   ....
}

[Archie]

I wanted to organize the composable functions in a Class:

abstract class Branding {

    @Composable
    abstract fun Title()

    .... 
}

to manage the NavGraph

fun GenericNavGraph(
   ...
   branding: Branding = rememberBranding()
   ...
) {
   composable("route") {
         GenericScreen(
            ...
            title = branding.Title,
            ...
        )
   }
   ...
}

Is this a good idea?

[Archie]

@jim is it possible to get some advice? Thanks in advance

[jim]

Most people who try the "composables on objects" approach end up regretting it in the long term when their code becomes a mess, but your milage may vary.  When designing Compose, we thought very carefully about how we wanted to structure the code to maximize developer ergonomics and long term maintainability, deviate at your own risk.  Ultimately it's your app, and Compose intentionally doesn't prohibit the pattern, so if it works for you, then do what works for you.

The challenge most people run into is (1) top-level functions are called statically, making it much easier to reason about data flow (since there is no data flow of code).  When you are passing around objects, it becomes harder to see what code is going to be invoked next. (2) Most people end up regretting some design decisions of their architecture, but much of your code ends up having baked in assumptions about the structure of these objects and it becomes much harder to refactor later.

If you are new to Compose, I might suggest trying to embrace the patterns we've established.  If you've been using Compose for a while, understand how it is intended to work and what the tradeoffs are, then you can start to deviate from the well-blazed trail.  Ultimately, you'll probably know when your ready to deviate because you'll be confident in your usage and won't feel the need to ask (the only answer you could hope for by asking is a generic "this is what works/doesn't for other people, which may or may not apply to you").

Good luck, and happy Composing!

[Archie]

I appreciate the advice! Thank you very much.