Dear Android Compose Team please do not re use the existing

Question

Dear Android Compose Team please do not re use the existing style system Android provides its a PITA to use right memorize extend and embrace Please come up with something better that doesn t force you to read and distribute base style information across dozens of files Thank you A plagued user

jim · Answer

Yes we re radically simplifying styles I think you ll like it much better basically just uses standard Kotlin code to create specify styles Still a work in progress but you can take a look at the material widgets samples defined in Compose for an early preview

alex009 · Answer

< jim> hello maybe you have some links to samples of material widgets from preview

Steve · Answer

How would you make sure that the new style system and the existing one stayed in sync

Adam Powell · Answer

So far by only doing it one way We can consume the existing styles for use in a compose sub hierarchy but since compose styles are dynamic we can t do the same in the other direction we don t have the compiled resource table entries for the existing code to consume

Adam Powell · Answer

We can pass through but we can t update unless the developer gives us an explicit static theme id when switching back to views

artem_zin · Answer

hopefully it ll be some sort of non static typed map lt attribute value gt with clear override composition api

Adam Powell · Answer

the current thinking is very much static typed the grab bag style has been a source of a lot of the confusion and frustration with the current system Definite yes to clear override composition API

Adam Powell · Answer

Rather than extending themes and styles by adding arbitrary properties to one collection we re looking at several separate use case and design system driven Ambient think tree local values that can be overridden and replaced for a given subtree e g theme colors typography and shapes when it comes to material widgets

Adam Powell · Answer

and you can define your own Ambients when desired if you want to add new things with similar cascading characteristics

Adam Powell · Answer

we re looking at putting drastically fewer things into theme like constructs like this no such things as default widget styles referenced from a theme etc

Adam Powell · Answer

and the things that do go in there are not meant to be widget specific rather they re general things that many widgets are meant to appeal to

artem_zin · Answer

sounds promising +1 I m sure you re on top of it but just wanted to list few obvious use cases Developer s slightly modifying default theme read Material Teams building default theme based design system for their app Teams building totally custom design system for their app There is also multi platform component to it but nailing Android specific API is a great start

Adam Powell · Answer

Yep those three cases are all top of mind

artem_zin · Answer

To the last point not meant to be widget specific not sure how this will play with type safety you re looking for heh

Adam Powell · Answer

for example a material raised button won t read a default raised button style and its background color from that instead it will read the current material colors take the primary color and apply it to its background Assuming no explicit color was provided to the use site of the button widget

Adam Powell · Answer

so for material widgets the theme ambients will map pretty directly to the material design spec <https material io design material theming overview html using material theming>

Adam Powell · Answer

and other design systems can use the same tools Ambients related patterns to implement theming that makes sense for those design systems

Adam Powell · Answer

rather than trying to create some platonic ideal of a theming system that tries to cover absolutely everything and then ends up needing arbitrary property maps

pavi2410 · Answer

Please I would like to have CSS for styling on Android