One Off the Slack: How Long Is Too Long?
Vitali Nartov asked a fine question:
Is there any concept in mind of how the composable should be decoupled or how big should/could be views/pages/screens with nested composable elements?
Google’s Jim Sproch said, in essenece, don’t worry about it:
for the size of Composables, it is a somewhat subjective judgement call. I think most new compose developers tend to be a bit paranoid about function length and try to break up composables into helper functions that are far too small. There are benefits to having large composable functions, like being able to use lexical scoping to get data to the appropriate child widget. In the absence of specifics, I’d tell people not to worry too much about length. Instead, focus on what pieces are reusable widgets that will be used elsewhere in your app, and make each of those into a separate composable function.
However, he went on to point out that while the entry point of a composable is a function, this does not mean that composables have to only be functions:
Widgets can (and should) have their own logic, and can introduce/expose their own classes and data model types. For example, a
DatePickerorCreditCardEntryFormorAddressFormcould all have very sophisticated validation logic. If you were implementing GoogleDocs, you might have aGoogleDocTextEditorwidget that took in a mutableRichTextDocdata structure describing the document. But the logic of these widgets should be self-contained to the widget’s specific concerns, and not explicitly depend on the app as a whole.
This feels like the sort of area where we will be refining our techniques in the years to come.
Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!