system-ui / theme-ui

Build consistent, themeable React apps based on constraint-based design principles
https://theme-ui.com
MIT License
5.29k stars 675 forks source link

Schema validation package #85

Open jxnblk opened 5 years ago

jxnblk commented 5 years ago

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 commented 5 years ago

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

okonet commented 5 years ago

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

jxnblk commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

alex-page commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

Would love to contribute. I made an issue https://github.com/system-ui/theme-ui/issues/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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

lachlanjc commented 1 year ago

@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 commented 1 year ago

@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.