And as a follow up, why? 2️⃣ seems much more discoverable to me, but 1️⃣ is more consistent with core compose APIs.
2 years ago
I would encourage you to think of Composables as Widgets, which is to say, as Nouns. You aren't drawing foo, you are placing a widget that happens to utilize foo.There are several reasons this is useful abstraction, but I'm not sure I have a super compelling/satisfying answer, other than to say the pattern generally feels better. People like to talk about a "Search Result" or a "DatePicker" or a "Box". Having it as a noun gives you a word to describe a thing on a page, and point to it and say "see, I mean this thing". I think this mental model tends to work better for the way that people think about the modules that make up a page/screen, especially as the widgets start having their own concerns like handling user inputs or driving animations.Another, maybe less compelling answer is that there are multiple ways a piece of data could be exposed. For instance, suppose you are implementing a bookstore and foo is a Book. You might have a search results page that renders several BookSearchResult(book) and another page that renders a BookDetailsPane(book) and another page that renders an AdminModeBookEditor(book). They're all valid views/representations of a book, so there isn't a single way to draw a book. Sure, you could implement all of them as extension functions if you wanted, but it would be something like
or something. You're forcing the noun form into a verb, which begs the question: why?Ultimately, it's just kotlin, and maybe you will discover a pattern that is better than what we've come up with. Feel free to share what you find/think!