How to map theme to properties

[alaboudi]

Thank you for this spec. I have been working on a side project that utilizes a theme with a shape similar to that in this spec. The one challenge I have is determining a systemic way to map values from the theme to styles in my React component library. I unfortunately do a lot of guess work. This is especially true when using values that are part of an array field (ex. sizes, space, etc).

Do you think it would beneficial to be more explicit about what each value in the array index would map to? For example, do you think we can benefit from saying something like theme.space[2] will map to things like button paddings?

The main reason I bring this up is because I'm assuming that my guesswork really beats the point behind using this theme spec. It would be unfortunate if someone was designing a spec but the components did not map them in the way they had in mind.

[peduarte]

If I understand correctly, you want to map CSS Properties to their respective theme scale. If that's the case, you can use Styled System's CSS function

[alaboudi]

Not too sure if we understood one another 😆but let me explain again. Let me start by saying that my question is not a technical but rather more of an architectural one.

I am assuming that one of the advantages of having a theme specification is to have interchangeable themes. For themes to be interchangeable, different theme designers should have a common understanding of which type of components are affected with certain values.

For example, assume a situation where a Button in a component library uses fontSizes[2] from the theme to decorate the button text. If another theme was used to replace the existing one, whoever designed that theme should have understood that fontSize[2] affects the button text. If the new theme was not made with the same considerations in mind, the replacement makes no semantic sense.

I guess what I am saying is that there seems to be a missing part to this spec (i.e. how the theme values get mapped to components). @peduarte hope that made sense. What's your opinion on this?

[peduarte]

Ah, I got you. It's an excellent question, and as you said, it's more of an architectural one.

I'm not totally sure what's the best way to achieve this without spending a few days thinking about the problem and prototyping ideas. At a glance, this doesn't feel like a problem to me, it's more of a change in mindset. As a designer creating a new theme, I don't think I'd care that fontSizes[2] will affect the Button. It probably would affect many other components too, so it's kind of tricky to create a relationship between a token and all its "consumers".

I am really curious how you'll approach it, please share your progress 🙂

[alaboudi]

@peduarte I was giving this some thought and I have come up with 2 possible solutions.

1. Theme specs should be component library specific: What this means is that maybe all themes should be developed within the context of a specific component library. The relationship between a token and its consumers are exclusively defined in the component files. This sort of makes sense.

2. Add an abstraction layer between tokens and components: Whenever I develop inputs and buttons, I generally tend to ensure their heights are equal. I do so because there is a possibility that I'll have an inline form and I'd want their heights to align. Rather than making this coordination implicit, we can decide to add a "use case" layer from which the components will indirectly read a theme value. For example, I'd create another JSON with a "formControlHeight" property and set it to a value from the theme. Buttons and Inputs would then read their height values from this property rather than the theme. This way the theme can evolve independently without ever being concerned about the consumers.

I like the second option as it seems to be more flexible. @peduarte what are your thoughts on this?

[jxnblk]

FWIW/ICYMI this spec hasn't been updated in a while, but I've written about some of the concepts around it here: https://jxnblk.com/blog/design-graph/ -- I think the concepts of scales and variants are particularly relevant to the conversation happening here

[alaboudi]

@jxnblk I like what you have done. Your graph solution is pretty much a version of the abstraction layer that I am talking about. I agree, scales and variants are very much important. I can see how people can argue that this may be tedious, but I think being explicit about the mapping advantageously explicit.