Is there a pattern for use by libraries of composables, so the library knows how to create composables from the app's design system? I am not worried about simple parent-child relationships, where we can get away with a

content

composable lambda. I am more worried about cases where the library itself should be calling composable functions for certain roles, but it has no a priori way of knowing what those functions are. For example, if a library wants to render a button, it needs some composable for that. But

Button()

is a Compose Material thing, and the argument made here on several occasions is that Compose Material is just one possible design system. Somehow, the library needs a way to know "this is how I build a button", in such a way that it uses the app's chosen design system. Do we have a pattern for doing this? For apps themselves, they can simply use the right composable functions, but published libraries do not have that option, as they will be used by many apps. My fear is that, in the absence of such a pattern, libraries will tend towards "you can have any design system you want, so long as it is Compose Material".

Published libraries that expose UI components need to pick a design system they're based on. There's no such thing as a design system agnostic component. (edit: that emits specific layout/UI elements anyway.)

Take a look at the variety of designs and details...

Agreed. For a component like a date picker, the library itself will basically be the design system for itself, exposing whatever options its authors wish. Teams wishing to use a date picker will choose among existing implementations for which one best fits the rest of their app's design, or they will elect to create their own if needed. However, not all libraries will be exposing something like a date picker. Composables are used for every unit of UI. Should an about screen composable be defining its own design system? Perhaps there aren't enough of these to worry about. I can't help but have this nagging feeling that we're going to run into problems. If the answer is that the app-specific design system is only useful for custom-crafted composables, it feels like we're going to have a lot of conflict between those design systems and libraries. Anyway, thanks!

What kinds of components do you think might be impacted by this mindset?

I suppose that my root concern is that Compose Material is going to be so unavoidable that custom app design systems are going to be a pain. And that if we don't take steps to help library authors make it easy to integrate their components into an app-specific design system, we're going to run into problems. For your date pickers, how are you envisioning that library authors will allow users of their composables to specify things like font details, foreground/background/accent colors, and the like? Even though the look and feel of an individual date picker is highly variable, they pretty much all have text and they pretty much all have colors.

If they're meant to be customized, then as parameters. If the component is meant to be design system-specific, then ambients CompositionLocals from that design system are likely to play a role

a treadmill of moving goalposts

The world needs a GIF of this. 😀 It would be wonderful if the Compose team could publish guidance for how you are envisioning composable libraries will look. There is quite a bit of expectation that the ecosystem will be filling in all sorts of gaps in the widget set, and the first generation of those libraries are going to be important for establishing community conventions. Again, thanks for your ideas!

I think some of it is likely to come in the form of examples from other jetpack libraries publishing compose-related modules or submodules

Have ambients been secretly replaced or something?

Nah just renamed

I’ve had a few conversations about design systems here, and the place I ended up at (and @Alexjlockwood ended up in a similar camp) is creating my own design system module that is very close to Material, but not. Our design system defines colors and typography that don’t quite line up with Material’s, so we have either forked the Material components or wrapped them in our own Composables. I’m actually very happy with it so far- most of the Composables are pretty small and straightforward to fork/wrap. Here’s the thread that originally led me down that path: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1603291475356800

Wouldn't such a question apply to any UI "platform"? If somebody wants to create a library of components for the web, I don't think there's a solution that would allow creating something like a date picker that feels seamless with every single web framework out there. Library developers have to make the choice on which design system they support.

One of the big differences with Compose vs. the View framework is that we are used to the View framework exposing a ton of configurable attributes (typography, all manner of colors, sometimes even shapes, etc.) because many of those are “optional” and exposing them is relatively easy to do. With Compose, those attributes would all map to function arguments which is a bit more noisy from an API perspective. The end result is that Composables tend to expose fewer attributes and are thus more opinionated from a design perspective.

yes, compose leans very hard into using composition to do those things rather than accumulating parameters on "canonical" components

But this still is not addressing the original question. If there are N design systems built on top of Compose, and I have an idea for a component (say, radial menu), what do I do?

yes, that's where the flexibility ideally lies in a design system library

Late to the party, but just came across this blog series: https://adambennett.dev/2020/12/migrating-your-design-system-to-jetpack-compose-part-2/ where the author walks through a migration of their design system to Compose. As they mention in the posts, a strong foundation requires:

A strong design spec, with “top-level” components and subcomponent variations, semantic colours (i.e. 

background

, not 

white

) and interaction guidelines

On top of that, the various layers are built: “primitive” components, “compound” components, etc. These basic ideas are of course Compose agnostic, but it seems as though Compose is infact fundamentally poised to realize these concepts way better than Views.