Building a Design System implementation using Jetpack Compose — Part2 (Component)

Howie Zuo
4 min readDec 30, 2020

Part 1

Part 2 (You are here)

It’s been a while since I post my last article talking about how to customize a theme for your own Design System.

My intention was to separate the whole stories into 2 parts like the way I explained how to build a Design System implementation for Android using the traditional(the one uses a lot of XML files) UI system (part1, part2).

This article supposes to talk about how to build Design System components using Jetpack Compose, but after been working on a Design System project for almost 1 year, I realized that there is nothing to talking about.

Because using Jetpack Compose to build components is much easier and everything just makes sense.

1. No API level hell 👻

We are running into this kind of situation a lot during our daily development life, a good API can solve all your problems but unfortunately is not supported by your current minimal API level.

It does not exist in Jetpack Compose!

But of course, this might change in the future, I hope Jetpack Compose won’t go back to the same loop.

2. Kotlin 💯% (or should say 99%)

Definitely the best news for all the Kotlin lovers.

Imaging here is a component called Avatar in the Design System.

Using the traditional UI system will be like:

Check my article about how to build a Design System component for Android

  • Styles for each size variant
  • A custom view for Avatar
  • An attribute for setting the default size variant for the Avatar (optional)

But in Jetpack Compose

  • All could be just one single kt file

Of course, XML resources are still functionally working in Jetpack Compose and useful in some cases, for example, handling screen orientation inside a component. But it’s good enough to build any component without depending on any XML files.

3. Visibility control 👁

In the traditional UI system, the styles or other things defined in XML potentially can be exposed unexpectedly or overwritten accidently by the definitions in other modules that have the same naming.

One solution I was using is making naming rules by given specific prefix like, dls , internal …, but you know it doesn’t solve the problem technically.

Thanks again for Kotlin, now it’s normal to just hide the things you don’t want to be exposed.

4. Everything can be Composable 🎼

The last one and my favorite, which is the most powerful feature in Jetpack Compose IMO.

Imagine how painful it is to build a component that has the capability to accept another component as input and showing it as part of its view in the traditional UI system. Which actually is common when thinking about a Design System component structure.

But in Jetpack Compose, it’s common to use the Composable function to build components.

You can see the body parameter accepts a component as an input which will be showing on the right side of the Title element.


This article was a short one, let me know if you find more cool things about building a Design System using Jetpack Compose.