Zach Klippenstein (he/him) [MOD]
01/19/2021, 8:23 PMButtonStyle
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
01/19/2021, 8:28 PMAdam Powell
01/19/2021, 8:28 PMZach Klippenstein (he/him) [MOD]
01/19/2021, 8:29 PMColton Idle
01/19/2021, 8:30 PMAdam Powell
01/19/2021, 8:31 PMandroid.widget.Button
as the platonic ideal of a button, and it led to no end of complexity in implementation and APIHalil Ozercan
01/19/2021, 8:34 PMAdam Powell
01/19/2021, 8:34 PMAlexjlockwood
01/20/2021, 3:36 AMenum
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]
01/20/2021, 5:04 PMjim
01/20/2021, 5:11 PM"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.
Zach Klippenstein (he/him) [MOD]
01/20/2021, 5:25 PM