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

[alex-page]

Would love to contribute. I made an issue #128, I have a rough work in progress here however it requires a lot more to be done.
https://github.com/alex-page/lollipop

[lemes]

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

For that matter there is also ts-io and Runtypes, libraries for doing runtime validation for typescript static types. I'm not familiar with it, but if I got it right, it solves the problem of having to maintain both the runtime validation and the type definitions.

[timkindberg]

Could always use jsonschema, it is an open standard for this exact purpose. Not sure if you can find a tiny library to do it though, ajv is like 25kb.

[hasparus]

Okay. I'm in need of JSON Schema for the Theme (my users are editting their themes from Django Admin).
Does anybody have one? 😄

[lachlanjc]

@hasparus My read 2+ years later here is great TypeScript support is enough (which we've got other issues for improving)—I think of TypeScript as the default for most developers, & if you're not using it you're aware you're missing out on validation all over the codebase. I'm not sure what you'd use this package for beyond that. Any other thoughts?

[hasparus]

@lachlanjc I'd keep this open, but the main reason an user would need this package is when you validate Theme UI themes at runtime... so if you build an app that's used to build other websites — like a CMS, or a MySpace profile page. Not a very popular use case.

I'd try ts-json-schema-generator as a starting point.