Hi everyone,
As I’ve been developing my Android app, I’ve quickly found myself in a situation, where all my @Composable functions are quite hectic, not really maintainable.
I am wondering, is there any guide for best practices regarding @Composable functions?
Thinking in Compose is a straightforward article, and it all makes sense - until I want to build something other than Hello World. Something more complex, I mean.
What I understand from the article is, that I should keep the logic out of these functions as much as possible, and pass only primitive types as parameters. Behavior should be kept in callback functions. This is very nice and clean, I like it, but then what should I do, when I have quite a lot of functions nested?
For example, on MainActivity I have a Scaffold, within that a NavHost with four different tabs, each with completely different content, some of them with a BottomSheet, which are also completely different for each tab (that has one), and some of the BottomSheets can call a Dialog, which again, has a form in it, and so on. So the hierarchy has quite a level of nesting. And if I understand the recommendation correctly from the article mentioned above, then I am supposed to keep the states and callback function definitions somewhere in MainActivity (or ViewModel), and pass everything through the entire hierarchy. Everything. The value of every single Text (those that cannot be hardcoded), all the list items to DropdownMenus, all the list items for Lists, literally everything. And then, according to the article, the renderer is smart enough to only recompose those elements that really changed.
To me this sounds tedious. I’ve also seen recommendations to just pass the ViewModel itself in order to reduce the number of parameters. But if I do that, then how would I make a @Preview out of it? Probably it’s possible, but it wouldn’t be convenient at all.
So what’s a clean approach for designing a good @Composable function hierarchy?
I generally have a view model per screen. I define a screen as a view that takes up most or all of the screen at one time. Each of your navigation items is one screen. Each bottom sheet I would count as a screen. There’s some flexibility in the definition. For instance if you have a dialog or bottom sheet that just has some small amount of information, it may not be worth creating a full separate view model. In the other hand, I find it useful to create mini view models for list items. YMMV there.