A modern programming language that makes developers happier.

kotlinlang

When building a custom design system component library in Compose, is the best approach to go one level below the Material Theme components' level of abstraction? So, for Button, go one layer down to Surface, etc.?

`Surface` is also part of the Material layer. If your design system is based on Material, it might make sense to build wrappers around material components, but if it’s not (and maybe even if it is) you can build everything on the `Foundation` layer and get rid of Material dependencies altogether.

Gotcha, something like <https://github.com/android/compose-samples/blob/fd7a5bb94808200df9fb8ccb8e17cb352c0aa5ae/Jetsnack/app/src/main/java/com/example/jetsnack/ui/components/Surface.kt|https://github.com/android/compose-samples/blob/fd7a5bb94808200df9fb8ccb8e17cb352c[…]app/src/main/java/com/example/jetsnack/ui/components/Surface.kt> perhaps…where a custom `JetsnackSurface` is created and the corresponding `Button` is built off of that.

Trying to think about concerns with maintainability; I guess its better to build off of `Foundation` and reconcile Compose API changes there, versus building off of some Material theme abstraction and then having Material theme API changes to sneak in to your custom components.