[docs] Use defaultCodeOpen where appropriate #25418
Conversation
| {{"demo": "pages/guides/interoperability/EmotionCSS.js", "hideToolbar": true}} | ||
|
|
||
| [](https://codesandbox.io/s/emotion-interoperability-idymy) | ||
|
|
||
| ```jsx | ||
| /** @jsx jsx */ | ||
| import { jsx, css } from '@emotion/react'; | ||
| import Slider from '@material-ui/core/Slider'; | ||
|
|
||
| export default function EmotionCSS() { | ||
| return ( | ||
| <div> | ||
| <Slider defaultValue={30} /> | ||
| <Slider | ||
| defaultValue={30} | ||
| css={css` | ||
| color: #20b2aa; | ||
|
|
||
| :hover { | ||
| color: #2e8b57; | ||
| } | ||
| `} | ||
| /> | ||
| </div> | ||
| ); | ||
| } | ||
| ``` |
There was a problem hiding this comment.
I'm commenting as it seems to be the intended objective of the draft PR.
Mainly interested why we had a separate codesandbox for this demo.
I would ask the same question. Why remove the codesandbox and the inlined JSX? These demos are meant to show that it works in isolation. I don't think that it matters that it works in our dev environment. I would even argue that it defeats the objective. We have used codesandbox and "hideToolbar": true as much as possible. "as much as possible", meaning up to a point where the maintenance pain of the sync of the codesandbox is acceptable.
@material-ui/styled-engine is meant to hide most of the underlying engine. It helps to switch to a different engine in the future if needed, and to provide extra features. We document emotion because developers might want to use it raw.
There was a problem hiding this comment.
We have used codesandbox and "hideToolbar": true as much as possible.
Why would we use it as much as possible?
Why remove the codesandbox and the inlined JSX?
Because we have existing code that does it for us.
There was a problem hiding this comment.
Why would we use it as much as possible?
The problem is:
- have these demos isolated (probably what's more important, to avoid depending on specifics of the documentation)
- not complexify the webpack config of the documentation for one-off use cases (e.g. CSS modules)
The solution was to:
Move them outside of the documentation. However, it comes with a maintenance cost. I believe we have both use a live demo (with different customization, only demonstrating the final output, with hidden sources), as well as showing the source for the most advanced portal to mitigate the cost.
Is it possible to improve the previous solution? Yeah, likely
There was a problem hiding this comment.
Oh, I definitely agree with the multi-file demos. But for single file demos that work just fine in our demo setup I don't see why we wouldn't use it.
There was a problem hiding this comment.
Yeah, agree, especially if the edit to codesandbox button in the toolbar works as-is.
eps1lon
changed the title
We don't need to duplicate code since we have
defaultCodeOpenwhich solves the same problem. Inline the demo source manually is only required for demos that span multiple files.Preview: https://deploy-preview-25418--material-ui.netlify.app/guides/interoperability/#the-css-prop
Based off of from #25416