Feature modules using components

[qwert2603]

Hello!

Now I'm creating the app using Decompose and I'd like to split the app into several feature-modules.
There is :api and :impl modules for each feature. :api module contains only interfaces with feature's public API, while :impl contains all implementation details.

I looked the "dynamic-features" example in this repo and noticed that interface Feature1 in :feature1Api contains properties and functions those are expected to be used by feature internals only. But now they are visible to other modules.

Seems like there should be interface Feature1 that is used by UI (@Composable fun Content is that case) and another interface that represents component to other feature-modules.

Is this the correct way for Decompose and are there any examples of such use case?

[qwert2603]

I've made some experiments and finished with creating separated interface for component, but extra cast is needed in :impl module. So it does not look fully optimal.

In :api module:

interface PostCommentsFeature {

    interface IPostComments

    fun createComponent(
        componentContext: ComponentContext,
        postId: Long,
        onBackClicked: () -> Unit,
    ): IPostComments
}

interface PostCommentsContent {
    @Composable
    fun Content(postComments: PostCommentsFeature.IPostComments, modifier: Modifier)
}

And in :impl module:

interface PostComments : PostCommentsFeature.IPostComments {
    val state: StateFlow<PostCommentsState>
}

class PostCommentsFeatureImpl : PostCommentsFeature, KoinComponent {
    override fun createComponent(
        componentContext: ComponentContext,
        postId: Long,
        onBackClicked: () -> Unit,
    ): PostCommentsFeature.IPostComments = PostCommentsComponent(
        componentContext = componentContext,
        postId = postId,
        onBackClicked = onBackClicked,
        postsInteractor = get(),
    )
}

class PostCommentsContentImpl : PostCommentsContent {
    @Composable
    override fun Content(postComments: PostCommentsFeature.IPostComments, modifier: Modifier) {
        PostCommentsUi(
            component = postComments as PostComments, // extra cast
            modifier = modifier,
        )
    }
}

May be there is better or recommended approach.

[arkivanov]

Hello. First of all, the main idea of the dynamic-features sample is to demonstrate how Decompose can be integrated with Android Dynamic Features, where modules are loaded on demand. It is required for feature modules to depend on the app module, which completely the opposite way of how feature modules should be organized. This is the only reason why I split features for APIs and impls. In all other cases personally I don't recommend splitting for API and impls, as in most cases it is an over-engineering.

Regardless of the reasons, I still find the way how it is done in the sample is correct. Consider you want to move the Feature1Content interface to another api module feature1UiApi. In this case feature1UiApi module should depend on feature1Api module. And therefore the provided Feature1 interface is valid. Therefore, I consider Feature1 and Feature1Content interfaces being APIs of the feature and its UI respectively, not APIs of the Gradle module.

But if you like the way how you are doing it, then go ahead with it. I don't have any reasonable objections, except maybe the cast.

[qwert2603]

Thank you for answer!

Consider you want to move the Feature1Content interface to another api module feature1UiApi

This is the use case that I didn't consider, and that should be supported.

Also, for me splitting api and impl is the way to compile less and to denote the module's API more explicitly.

[arkivanov]

Yeah, if you see enough benefits of such an approach, then go ahead with it! I just expressed my personal opinion. I think that the internal keyword in Kotlin works very well to "denote the module's API more explicitly". And also I think that the "to compile less" statement assumes the current situation with Gradle. Not all build systems are affected by this. From my point of view, the build system should affect the architecture only if there are measurable concerns. But again, use what works for your project better! Splitting for API and impl is a completely valid approach.