Decompose for big scale multi-module projects

[styagailo]

Hello Arkadii,
Thanks for the library.

We are adapting Decompose at our fintech project on Android.
There are hundreds/thousand modules following api/impl modularisation pattern.

We have classic scenarios:

• feature can run another features
• root can run features via deeplinks
• nested deeply in the navigation stack feature can run a full screen feature on top.

I checked an example https://github.com/arkivanov/decompose-dagger-sample
but I see each module exposes Composable, and Root composable will know everything about all child composables.

Educational case:

• FeatureA
• Single RootComponent
• 3 ParentComponent (childs of Root), they all have FeatureA as child

Does it mean that for each ParentComponent, I will need to provide FeatureAComponentProvider, FeatureAComposableProvider (to hide implementation details of the feature)

Don't you mind to share some ideas how to approach such architecture?

[arkivanov]

The decompose-dagger-sample example doesn't follow the api/impl structure. In that example, both feature-root and app-android can see all feature component interfaces, implementation classes and Composable functions.

If you want to follow the api/impl structure, then unfortunately, Composable top-level functions can't have a separate API module. You'd need a workaround for it. From the top of my head, there are two options, each with their own pros and cons:

1. Include Composable functions in the Component interfaces.

interface FeatureAComponent {
    val state: StateFlow<FeatureAState>

    @Composable
    fun Content()
}

Pros: feature impl modules only depend on child api modules and do not depend on child impl modules.
Cons: component interfaces and classes directly depend on Compose.

2. Create a separate interface for Composable functions.

interface FeatureAComponent {
    val state: StateFlow<FeatureAState>
}

fun interface FeatureAContent {
    @Composable
    operator fun invoke()
}

Pros: component interfaces and classes do not depend on Compose.
Cons: more interfaces; feature impl modules will have to depend on child impl modules in order to call their Composable functions, unless you leverage DI for this as well, which is even more code to write.