I've been contemplating this all morning, and I think these are the main priorities:
Generate an easily-deployed brochureware site with documentation, examples etc (ie, the artefact itself)
People who use the HTML elements and classes they see in the documentation must get the same resulting experience as people who use the equivalent react components, if they’re using the same stylesheets.
We need something in place to make sure #2 remains true, otherwise they’re likely to quickly diverge. This goes for content level components like <WeatherIcon> or forms, as well as things like whole-page layout and/or navigational components, such as <PageHead> and <PageTabs>
#3 is something we can achieve by automated verification, or by generating one of these artefacts from the other. I’m leaning towards generating parts of the documentation directly from the react components (where they exist) but I’m definitely open to suggestions or hurled chairs. I don’t want to code us all into a corner I didn’t foresee if somebody has an angle I’m not considering.
Josh McDonald
added a comment - I've been contemplating this all morning, and I think these are the main priorities:
Generate an easily-deployed brochureware site with documentation, examples etc (ie, the artefact itself)
People who use the HTML elements and classes they see in the documentation must get the same resulting experience as people who use the equivalent react components, if they’re using the same stylesheets.
We need something in place to make sure #2 remains true, otherwise they’re likely to quickly diverge. This goes for content level components like <WeatherIcon> or forms, as well as things like whole-page layout and/or navigational components, such as <PageHead> and <PageTabs>
#3 is something we can achieve by automated verification, or by generating one of these artefacts from the other. I’m leaning towards generating parts of the documentation directly from the react components (where they exist) but I’m definitely open to suggestions or hurled chairs. I don’t want to code us all into a corner I didn’t foresee if somebody has an angle I’m not considering.
jmcdonald Don't know if this helps but I am less interested in allowing people to use our CSS directly – could the JDL just be a react framework?
James Dumay
added a comment - jmcdonald Don't know if this helps but I am less interested in allowing people to use our CSS directly – could the JDL just be a react framework?
If we don't let people use the CSS directly, we don't really let people integrate non-react components. Currently, we don't have any support for non-react components, anyway. I like the idea of JDL being react only, it would simplify our lives considerably. It ends up being sorta like the jelly tags today: here's the easy way to do it. Or you can do your own thing, but just know that you have to figure a lot more out on your own...
Keith Zantow
added a comment - If we don't let people use the CSS directly, we don't really let people integrate non-react components. Currently, we don't have any support for non-react components, anyway. I like the idea of JDL being react only, it would simplify our lives considerably. It ends up being sorta like the jelly tags today: here's the easy way to do it. Or you can do your own thing, but just know that you have to figure a lot more out on your own...
Lets keep it React only for now – if there is demand to extract the CSS into its own framework we can bite that off later on. We just have to keep that in mind as we build out the JDL (no inline styles, etc)
James Dumay
added a comment - Lets keep it React only for now – if there is demand to extract the CSS into its own framework we can bite that off later on. We just have to keep that in mind as we build out the JDL (no inline styles, etc)
Once this is setup I suggest that jmcdonald and sthebridge pair together adding a single design element to the site