I’ve been following along with the suggested style...

# decompose

[Landry Norris]

I’ve been following along with the suggested style in the guide, and over time, I’ve kind of settled on a style of my Component files having an interface FooLogic that has a val state: Flow<FooState> and any functions my UI should directly interact with, then a FooComponent that implements FooLogic and defines state as MutableStateFlow, then create a data class FooState with defaults for all its parameters. I notice that over time, FooLogic becomes quite large, often having over 30 methods. Is there a good way to handle my Components as they scale?

[Landry Norris]

Maybe some sort of style guidance on when a child component should split off?

[Arkadii Ivanov]

There are no strict rules here, of course. Basically, when you realize that a component became complex, it's advised to extract a meaningful part of it into a child component. Ideally that part should be self-contained, e.g. be easily extractable and decoupled as a piece of code. E.g. in a chat screen, the input bar is a good example of a candidate for extraction.

A big amount of methods in the component's class/interface is a good sign of complexity, however not always. If it's difficult to locate a meaningful part to extract, either the implementation details should be refactored. Or just extract the code from the component's class to separate internal classes, so the component class is just a thin proxy.

[Arkadii Ivanov]

In the last approach, you can try segregating the component's interface - extract methods to a number of separate interfaces. Then implement those interfaces by internal classes, and use delegation in the component's class definition.