Google is continuing to clean up the Compose UI API to center around design systems.
As I covered previously
, a Compose design system is basically a set of composables that implement the core building blocks of your designers’ desired aesthetics. If your designers want buttons with a particular background color, shape, and border, you create a composable that defines such a button, so the rest of your code can then just use that composable. If the designers change their minds and tweak what that button should look like, you change the button composable in your design system, and everything else automatically adopts the change.
In the end, it appears that we will be getting roughly three categories of composables in Compose UI:
- Composables that do not draw anything themselves. Key examples of this are your containers: Box(), Row(), Column(), LazyColumnFor(), etc. While a design system will use these composables, usually you do not need a CompanyBox() or a DesignRow() that somehow embodies design rules.
- Composables that handle basic operations and are unopinionated (and perhaps are a bit plain as a result). It appears that Google is standardizing on Basic as a prefix, so we get BasicText(), BasicTextField(), etc.
- Composables that implement Material Design as a design system based on those Basic composables. So, Text() and TextField() are now material composables and adhere to Material Design aesthetics. These offer limited flexibility, specifically because they are supposed to adhere to Material Design rules.
If your designers are sticking pretty close to Material Design, your project’s design system can be based on the material composables, wrapping them to configure them for project design standards. If your designers are ignoring Material Design, your project’s design system will be based on the Basic family of composables, wrapping them to apply your desired aesthetic.
Google’s apparent objective is for teams to use package names to distinguish composables from different design systems. For example, you might have org.awesome.compose.design.Text() that wraps the material edition of Text(), so you can still use Text() as the composable name. That, in turn, will drive the creation of Lint rules to help ensure that only the design system uses the material edition of Text(), as auto-complete may cause developers to accidentally use that instead of the design system’s Text().
Personally, unless we get some really good tutorials or other solutions for creating and maintaining those Lint rules, my guess is that projects will lean towards AwesomeText(), with a prefix denoting the design system, to better distinguish the design system’s composables from those supplied by Compose UI. There is a bit more discussion of this point in this week’s “One Off the Slack” entry
Regardless, I think the Basic cleanup is a good move. The more that material can be a true design system atop of Basic, the more likely it is that teams will have success creating their own similar design systems.