Question for Compose devs working on Material – why did yall make the decision to represent different button styles as different composables with different names, vs something like just passing a

ButtonStyle

enum as a parameter? Given that Material has a fixed set of button styles, it seems like the parameterized version would be less code (1 fun vs 3), less duplication in documentation, and more discoverable.

This was a topic of much passionate discussion, with many valid pros and cons. It's mostly a result of a fundamental shift in the way we want people to start thinking about widgets. You should not be afraid to build your own, and what you build should be no different from what we would do if we wanted to add our own variant. We do not want to take a privileged position in the ecosystem. Furthermore, while it seems like many things could be shared, that ends up leading to large monolithic composables with lots of complex and subtle mechanics in their internals. By breaking them out into separate composables, we ensure that we are adequately providing the necessary building blocks that allow implementations to be written without too much complexity, so when you go to build your own button, you can do it quickly and easily just like we did.

yeah basically that. It only takes one parameter that is only relevant for one of the button styles and then the whole API falls apart

Thanks for your responses! We’re trying to figure out the tradeoffs here for our own design system, so this is helpful.

Running into the same "question". Thanks for asking it @Zach Klippenstein (he/him) [MOD] We started seeing components with tons of if statements in them and ended up breaking them out anyway.

it was a key insight that we picked up from the flutter folks in the separation of design libraries in general. Through Android's design revamps over the past decade and especially as the mdc-android library grew, for years we fought tooth and nail to keep

android.widget.Button

as the platonic ideal of a button, and it led to no end of complexity in implementation and API

So, it begs the question "what's the cutout between function parameter and a whole different component?" The answer probably depends heavily on the specific UI component. In other words, if a simple cornerRadius + elevation makes the difference between two styles, would it make sense to separate them into different composables?

We spent a lot of time telling the Android design team, "no" on the grounds that we couldn't keep API compatibility in the presence of suggested designs, both in the Holo revamp and Material.

fwiw we chose the

enum

route here and it has been working well… the main reasoning being we tend to have more component styles than material, and it was overall less verbose to just have an

enum

parameter compared to creating a separate function for each component style. but that is just us 🙂 we also figured we could pretty easily migrate over to the non-enum approach if we ever needed to in the future, which i guess is probably not as easy of a migration for the material library (since we aren’t publishing any of our stuff publicly)

We’re currently leaning towards the enum route too, I think for similar reasons. More component styles, and we don’t care as much about serving as an example for how to create custom components since we are more opinionated about wanting developers to only use the declared styles as much as possible. And also yes, this seems like a Type 2 decision - easy to back out of if necessary.

"we don’t care as much about serving as an example for how to create custom components"

Famous Last Words. Often these decisions end up building on each other in ways that isn't immediately obvious. If I were giving you advice, I'd suggest you follow a pattern more similar to what we are doing with material, rather than trying to use an enum. Having said that, one of the great things about Compose is that the technology is unopinionated and you are free to violate my recommendations and learn your lessons the hard way.

My bad, could have worded that better (a bit distracted watching the inauguration 😜). I probably did interpret your initial message a bit too narrowly. We’re aware of the monolithic risk, and we’re rolling this out very slowly so if things become untenable we should be able to correct course before it’s too late. Also, we do expect custom components to occasionally be needed, so we’ll also definitely be gathering feedback around that experience. We’re super early in this process so this discussion is super helpful, thanks again for all the responses!