Question for Compose devs working on Material – wh...

# compose

[Zach Klippenstein (he/him) [MOD]]

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.

[jim]

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.

[Adam Powell]

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

[Zach Klippenstein (he/him) [MOD]]

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

[Colton Idle]

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.

[Adam Powell]

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

[Adam Powell]

there were a bunch of things that made us fight for that. In part it was because writing a custom view has such a high activation energy to make it worth it; for feature requests in isolation it seems easier to just add new APIs to an existing view but that scales poorly.

[Halil Ozercan]

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?

[Adam Powell]

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.

[Adam Powell]

Being able to make clean breaks at will is hugely valuable

[Adam Powell]

@Halil Ozercan it can; some of it relates to how people use and think about a component. Material makes distinctions around where things like ink buttons (not sure if that's still the accepted term?) or raised buttons should be used from a semantic perspective. Those make good separate components; when the "styling" carries semantic meaning and usage recommendations

[Alexjlockwood]

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)

[Zach Klippenstein (he/him) [MOD]]

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.

[jim]

"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.

[jim]

It's more than just serving as an example, perhaps the wording in my initial response was somewhat incomplete. By breaking out your widget into composable parts (necessary for reuse across composables), you ensure you are not creating a monolithic mess. Your code will likely end up having more reusable constituent parts and often better data flow and modularization.

[Zach Klippenstein (he/him) [MOD]]

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!