One Off the Slack: Deduplication and Composables

Chris asked:

How do you know where to draw the line when building components? How was it decided to build a Box but to not create a Circle composable? I find myself wanting to break everything out into reusable components and rather than just creating the page I need, I end up building a whole infrastructure of components behind it.

Later in the thread, Google’s Sean McQuillan provided a direct answer on the Box-and-Circle concern:

In terms of general de-duplication, Zach Klippenstein cited the rule of three, which basically states “two copies is fine, three copies suggests refactoring”

However, there are other concerns to take into account:

Google’s Adam Powell mentioned that he is “22 pages into a draft of compose API guidelines”. That will be a fascinating document to read if it is public (versus being purely for internal Google consumption).

I also agree with Sean McQuillan’s comments on how composables likely will evolve in larger projects. While it may be tempting to make your screens based directly on common composables like Button, you will need to take into account how you plan on having a centrally-defined look-and-feel for those widgets. Projects may wind up with a library of app-specific composables that just call through to stock composables (like Button) with default parameter values that impose the common style. Or, as Sean put it:

Basically, encapsulating the contract of “this is what a Button will look like / do” and then using it instead of the framework Button I’d expect in a largeish code base (10+ devs) it’d make sense to make a custom version of most of the drawing components with a API that only supports what your app allows (Text, Button, etc). Probably less often for layouts (Row, etc)

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!