Is there any best practice or opinions on what lev...

# compose

[caelum19]

Is there any best practice or opinions on what level of granularity we should create components at, i.e. how much nesting in the absence of reuse should there be (if ever) before creating new components?

[mbonnin]

when you need a second screen on the right 😅

[Mark Murphy]

Unfortunately, "component" is an overused word in Android (and arguably in software development overall). Could you explain a bit more about what you mean in this context?

[caelum19]

Composable* sorry 😅

[Mark Murphy]

My gut instinct is that it will be not that different from anything else. Ideally, we avoid huge functions anywhere. And, ideally, we avoid going overboard on breaking a decent-sized cohesive function into a bunch of scattered independent functions. IOW, "all things in moderation".

Personally, I do not yet have a sense for whether Compose will tend to drive us towards larger or smaller functions, though.

[Adam Powell]

Some folks on the team with a lot of react experience advocate for longer functions being just fine as long as the purpose is still readable, as the spatial locality of keeping things together can outweigh the abstraction benefits of breaking it up. In my own experience with compose so far, if you're doing the kotlin thing of named parameters one per line when things get longer, composables can stay quite readable in the 100-150 line range if they're basically a layout of a bunch of other composables with minimal binding logic