Hi all! Curious if anyone has dealt with building a design system in Compose, where the design system specifies many tokens (in the 100s)… The Jetsnack approach for defining Colors, Type, etc as classes with

MutableState

fields might not be scalable for a system with a lot of tokens. Thinking about possible approaches, esp ones that minimize recompositions as much as possible, such as maintaining a

Map<Token, MutableState<Color>>

etc…Would love some suggestions on this 🙏🏼

The reason Jetsnack (& also Material Design) uses mutable states for each property is to minimize recompositions itself. This way, the granularity of the changes is at the property level and if you are using a property that did not change, it won't recompose it.

Totally, which is why one of my initial thoughts to minimize potentially 100s of member fields was to maintain a static

Map<Token, MutableState<Color>>

instead. This way, one could query for a particular kind of color, and access it’s corresponding

MutableState<Color>

… But I’m not sure if it is problematic to have

MutableState

as a map entry in this particular case…

oh maybe I misunderstood what you initially said 😅 I'm unsure about what it would do if the value of the map is a mutable state object 🤔 There's

mutableStateMapOf

that might be useful for you but I haven't tested its behavior. Definitely worth testing with that!

oh haha no prob. yeah for sure, tying out some approaches with

Map<SemanticToken, MutableState<Color>>

, etc. will see how it goes. trying to measure recomp here by logging in a

SideEffect

or something