Hi all, I have write some complicated screens some...

# compose

[abbic]

Hi all, I have write some complicated screens sometimes and im starting to be concerned about the readability of the code when it gets so deeply nested.
Generally i am of the opinion that if a function isnt reused anywhere it should just be inlined. I think that's fine for a lot of cases but i want to have a consistent way of extracting child composables for the specific purpose of readability, because when things get super nested i start to feel bad

One of the problems is that Compose is very expressive and 2 different people (or the same person on different days) could come up with very different ways of extracting new composables out of the screen. if possible i would like some rules of thumb for what to extract and why and when, to make this kind of refactor work consistent for myself and my team. would anyone with opinions or habits in this regard share them?

[Stylianos Gakis]

I just extract parts of the screen that look self-standing, even if they're not used anywhere else when it starts getting too nested.
Keep those functions private of course and that's pretty much it.
Sure it's not super consistent screen to screen, but that's fine.

[abbic]

that's fair enough, thanks!

[Alex Vanyo]

My 2 cents - I would avoid trying to achieve a “perfect” refactoring according to rules that are super strict. You’ll probably need to add functionality, move pieces of UI around, or change the design in some way in the future. Trying to adhere to strict rules could result in code that ends up being harder to read or more confusing when you do need to make those changes

[Alex Vanyo]

For refactorings, I’d also try to keep those separate from behavioral changes for review purpoess. I’d much rather review a PR that has two commits with “Refactored in preparation for new logic with no behavior changes” followed by “Adding new logic” then trying to review a single commit that does both together

[Zach Klippenstein (he/him) [MOD]]

Definitely second what Alex said. A guideline i try to use in these cases is to structure things such that when you’re reading the highest-level function, the logic and calls it does express the intent at the highest level, so someone reading that function can gain one level more of understanding of what it actually does, but not more. And then apply that recursively down as well. Often these decisions are also informed by what kind of data or objects need to be passed around between the second-level functions—if you’re just passing tons of data to each one, then it’s not much clearer. Each lower function should have a single purpose and ideally operate on a smaller chunk of the data that the higher-level function knows about.