Schema validation package

[jxnblk]

A schema validation for Theme UI objects could help with other packages and libraries built on top of the core. Leveraging a library like yup or joi, this validator should be able to detect whether a theme object is valid and detect typos among other things

[jxnblk]

Just remembered there's also the superstruct package, which might be worth considering

[okonet]

Would you consider also using typescript for that? I think that would increase the adoption and help with completion etc in IDEs.

[jxnblk]

I think some sort of typescript support would be nice – but I think there’s value in having a runtime schema validating as well. If you have ideas for anything to add to make typescript development better, I think that could make a great addition to the library as a whole

[okonet]

I think to have good TS support would require to write the library in TS. Not sure what’s your stance on that. I’d love to have first-class TS support out of the box.

[jxnblk]

We’ll probably not change the core to use ts since we want to keep a fairly low barrier to contribute, but I’m guessing some optional ts-specific packages could make sense. Especially around creating and using the theme object - at the very least some type definition modules could probably help

[VinSpee]

I started prototyping this: https://codesandbox.io/embed/compassionate-euler-xgzxb?codemirror=1

Some questions:

1. Should we support unlimited nesting?
2. Do we support css variables? They’re easy to support and I can imagine the use case but they’re not guaranteed to be of The type we’d expect.

[alex-page]

I have been building something that generates css variables from the schema. I think this would be an abstraction from the actual schema as the schema should be able to generate react props, css variables, sass variables, design files, spreadsheets etc.

[VinSpee]

@alex-page that's where my gut goes too, but I'm not certain that it's the right decision.

[alex-page]

@VinSpee after reading this article by the maintainer I think that is there intention:

Styled System is one small attempt at a higher level of abstraction on top of the current CSS-in-JS libraries. It's completely decoupled from Styled Components, Emotion, and even React itself. For the most part, Styled System uses CSS property names as React component props, which is something that other libraries do as well and doesn't require much additional learning if you already know some CSS.

Where I see differences start to arise is at the theme definition level. Even outside of React context-based theming, a lot of React applications will store global style constants in a common module. Something I'm starting to notice is that there are no standard conventions for what that module contains or how its structured, but all of them seem to be doing the same thing, in a slightly different way.

I suspect a lot of the tooling for styling applications would benefit from having a standard theming format for storing these values.

[VinSpee]

yes, and also from Brent:

https://twitter.com/jxnblk/status/1142137365164646402

If you want a universal standard for design tools, start with HTML & CSS, some of the most widely adopted standards in the world. They're declarative, static, JSON serializable, and are governed my standards bodies (also CSS Grid Layout is pretty powerful)

[jxnblk]

I have been building something that generates css variables from the schema

@alex-page I think this would be a great addition to theme-ui as a stand-alone package. I imagine the schema package would be something that could be leveraged for this, but it probably warrants its own issue if you’re keen to contribute

[jxnblk]

@VinSpee that looks awesome! I don't know if I have any definitive answers for you, but here's my initial thoughts:

Should we support unlimited nesting?

I think that would be good. A lot of people use nested color objects, so it'd be great if most existing styled-system and related themes would still be "valid" so to speak.

Do we support css variables? They’re easy to support and I can imagine the use case but they’re not guaranteed to be of The type we’d expect.

If you mean should you be able to add custom properties as values to the theme object, then I think the answer would be yes. There could be additional stuff built on top to help with how those custom properties actually map to the theme object, but I think that would be out of scope here