Hi all! Curious if anyone has dealt with building ...

# compose

[Tash]

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 🙏🏼

[Vinay Gaba]

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.

[Tash]

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…

[Vinay Gaba]

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!

[Tash]

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