Twitter | Search | |
Brent Jackson
I would love to see more standardization around how theming is handled in React so I started a theme specification (which isn't coupled to Styled System). Tell me what's missing or why you wouldn't adopt something like this
Style props for rapid UI development
Brent Jackson Brent Jackson @jxnblk
Reply Retweet Like More
Brent Jackson Mar 21
Replying to @jxnblk
Reply Retweet Like
Brent Jackson Mar 25
Replying to @jxnblk
And the theme specification has a new home, decoupled from the Styled System library! Feel free to comment on the open issue to keep the discussion moving forward
Reply Retweet Like
Brent Jackson Jun 28
Replying to @jxnblk
Curious to hear others thoughts on this RFC for an optional "level 2" portion to the Theme Specification, which is meant to make theme objects themselves more portable:
Reply Retweet Like
Ian Storm Taylor Mar 19
Replying to @jxnblk
Why is everything plural except for `space`, when using `spaces` would work just as well but eliminate the outlier?
Reply Retweet Like
Brent Jackson Mar 19
Replying to @ianstormtaylor
Tech debt?? I haven’t changed that in styled system to avoid breaking changes. I’ve seen others use `spacing` for a key in the wild as well. To me the word "spaces" sounds like interior design whereas “space” implies visual design, e.g. negative space
Reply Retweet Like
Brent Jackson Mar 19
Replying to @ianstormtaylor
That outlier does bother me a little as well though
Reply Retweet Like
Ian Storm Taylor Mar 19
Replying to @jxnblk
Tech debt makes perfect sense. I personally went with `lengths`. I think as a spec it could benefit from more separation from Styled System if you want it to be considered as such. The tech debt shouldn’t be canonicalized.
Reply Retweet Like
Brent Jackson Mar 19
Replying to @ianstormtaylor
Agreed. I don’t mind the space naming convention though and I feel like I’ve seen a lot of similarly named scales. Do you use length for all CSS length values? Or just margin/padding?
Reply Retweet Like
Ian Storm Taylor Mar 19
Replying to @jxnblk
I try to use it for all dimensions, because I haven’t found a good reason to distinguish. I tend to need to use widths/heights that match margins/padding’s, so having it all as one scale has been helpful.
Reply Retweet Like
Brent Jackson Mar 19
Replying to @ianstormtaylor
That’s a fair point. I tend to use font size and “build out”
Reply Retweet Like
Brent Jackson Mar 19
Replying to @ianstormtaylor
I might move this bike shedding to a github issue to discuss further and get more perspectives
Reply Retweet Like
kristo🚲👷🏼‍♀️🚌🏗🏢 Mar 18
Replying to @jxnblk
What do you think about having color intents like a material design palette so that you are tying components to intents not a specific color? I hate refactoring colors.tomatoRed to colors.fireRed
Reply Retweet Like
Brent Jackson Mar 18
Replying to @jesus__kristo
This spec intentionally avoids color abstractions (because they are wildly complex) so your example *should* work – colors can be whatever shape you want
Reply Retweet Like
kristo🚲👷🏼‍♀️🚌🏗🏢 Mar 18
Replying to @jxnblk
I guess it’s that complexity I’m hoping to standardize / deal with
Reply Retweet Like
Brent Jackson Mar 18
Replying to @jesus__kristo
I would love a complementary spec just for colors – I feel like that’ll be far more difficult for people to agree upon as a standard though
Reply Retweet Like
Darin Dimitroff Mar 18
Replying to @jxnblk
Something I’m still unsure about is storing component variants in themes. Still find it more brittle compared to having a BaseButton component that I extend or something similar.
Reply Retweet Like
Brent Jackson Mar 18
Replying to @deezel
Yeah I would be okay ditching that part of the general spec. It’s mostly documented now because Styled System supports it
Reply Retweet Like
Darin Dimitroff Mar 18
Replying to @jxnblk
Don’t get me wrong, it’s useful and kind of eases the transition from older, heavier themes for some people. Just not as foundational as the other stuff for me.
Reply Retweet Like
Brent Jackson Mar 18
Replying to @deezel
Agreed
Reply Retweet Like
Rob Gordon Mar 18
Replying to @jxnblk
Different designs will call for different encodings of their tokens. Having a library of techniques to mix and match seems ideal. That said, the design system I’m working on now looks a lot like yours 😏
Reply Retweet Like
Brent Jackson Mar 19
Replying to @_____rob______
This isn’t a library and doesn’t dictate what file format to use. This could very well be written in json, yaml, toml, or whatever you want to use
Reply Retweet Like
Rob Gordon Mar 19
Replying to @jxnblk
File format? By encoding of tokens I mean the choice between dark/darker/darkest or [100,200] for colors; or using a modular scale or fixed font sizes for type. Different designs will call for different data shapes and tools is what I meant.
Reply Retweet Like
Brent Jackson Mar 19
Replying to @_____rob______
Yes, the only standard proposed here is to name that object `color`, not `palette` or whatever else – the color abstraction and shape of the object is out of scope here
Reply Retweet Like