Keep root components from being huge

[pavelkorolevxyz]

Hi. Thanks for amazing lib. I wonder what options do we have to slow down component growth if we talk about some root components.

Let's say we have an app like Twitter, so we have AuthorizedRoot with all these bottom tabs and a lot of other screens open on the same navigation level. For example Single Tweet screen, Account screen, Compose New Tweet screen, Photo Attachment screen, Video Attachment screen and much much more.

So basically our DefaultAuthorizedRootComponent may look kind of like this:

class DefaultAuthorizedRootComponent(  
    // Dependencies for all child components  
) : AuthorizedRootComponent {  
  
    private val _childStack = childStack(  
        source = navigation,  
        initialConfiguration = Child.Loading,  
        handleBackButton = true,  
    ) { child, componentContext ->  
        when (child) {  
            is Child.Loading -> AuthorizedRootComponent.Child.Loading  
            is Child.Main -> createMainChild(componentContext, child)  
            is Child.Account -> createAccountChild(componentContext, child)  
            is Child.PhotoAttachment -> createPhotoAttachmentChild(componentContext, child)  
            is Child.VideoAttachment -> createVideoAttachmentChild(componentContext, child)  
            is Child.Compose -> createComposeChild(componentContext, child)  
            is Child.Hashtag -> createHashtagChild(componentContext, child)  
            is Child.Tweet -> createTweetChild(componentContext, child)  
            // Other components  
        }  
    }  
  
    private fun createAccountChild(  
        componentContext: ComponentContext,  
        child: Child.Account,  
    ) = AuthorizedRootComponent.Child.Account(  
        component = DefaultAccountComponent(  
            componentContext = componentContext,  
            deps = AccountScreenDeps(  
                // Bunch of account screen dependencies  
            ),  
            onBack = navigation::pop,  
            onNavigationEvent = { event ->  
                // Bunch of account screen intents to open something on current hierarchy level  
            },  
        ),  
    )  
  
    // All other create child functions which are pretty long  
  
    @Parcelize  
    sealed class Child : Parcelable {  
        object Loading : Child()  
  
        data class Main(  
            val session: Session,  
            val account: Account,  
        ) : Child()  
  
        // Other children  
    }  
}

I believe I am losing control on how much code do I have here with every new feature. Like what if I add Settings, Direct Messages Chat screen, anything else which I want to open on top of Main bottom nav screen, not inside its tab. If I continue I'll get long when statement, a lot of child create methods, long Child sealed class here. How do you think we should decompose (no pun intended) such big components to smaller ones? All of these features are kind of on the same business level, it feels unnatural to separate them.

[malliaridis]

I think what you are asking are very important questions that do not have a single answer and may also be very opinionated. I think it strongly depends on how you normally organize your code, what your previous experience taught you and on what project and part of the project you are currently working. The library and frameworks in general with their sample projects are a great starting point and provide you a lot of best practices, but they are not always fitting well into your project's needs and provide often only basic use-cases.

If I had to give you a quick answer it would be "Prefer to break things down. Components should be light-weighted and having a lot of components is to be expected in production-ready apps." But someone might give you a better or completely different answer.

That's why I want to share a few tips that helped me organize larger (normally production-ready) applications (you may already know these, but see them as a reminder then).

Create and keep up-to-date an information architecture and navigation system

No matter at what stage your project is, having and updating the information architecture and the navigation system (typically as a graph) will help you to quicker identify possible abstractions and relations between components. It may also allow you to recognize various data flows that may not be obvious at first.

Remember the SOLID principles

The SOLID principles contain valuable information on how you should design your components, how to abstract and couple things together. They play an important role in object-oriented programming and also in software architecture.

I strongly recommend to document your components. This helped me focus more on the single-responsibility principle, because once I started writing down what a component's role was, I realized that I was giving it too many responsibilities. Only then I realized that I had to split it even further and create various components with different responsibilities. And thanks to the AI assistant I now write much more doc comments.

Try things out and don't be afraid of changing things over time

Probably the most important thing for me is trying things out. Go with a solution and don't loose time. And if it won't work out, make the necessary changes. It's hard to find the perfect solution on the first try and because the requirements of a project are constantly changing, you will have to reevaluate and rewrite parts of your project.

Thanks to the great practices and design patterns that are followed and used in this and other related libraries, it is quite easy to make changes and don't introduce often crucial and large-scale changes. Starting with fewer components and later splitting them up to multiple components, abstracting them with wrappers or interfaces and rewriting them is part of the software development process and easy to master. Just know your code's limitations, try alternatives and form your own and unique experience based on your needs.

Additional notes

Some important features of Decompose that are worth mentioning for all your planning and designing are:

• Child components in general
• Custom component contexts, useful for things like AuthX and AuthZ (see for example Adding a child component manually with a custom ComponentContext #205)
• ChildStacks but also ChildSlots

[arkivanov]

Thanks for the good answer! I would summarise as two general rules:

1. Identify components with too many responsibilities and decompose them by multiple smaller feature components. E.g. extracting tab navigation into a separate component containing all tab children. Or extracting a flow into a separate component: e.g. a component for composing a tweet could contain child components for typing the text, selecting GIFs, attaching media, etc. A component that only encapsulates children without any additional logic also sounds reasonable, even if the amount of child components is big.
2. Extract code out of a component into separate classes. E.g. if you believe child factory functions take too many lines of code, feel free to extract that code into separate class(es).