mdx: [idea] Parse fenced code block metastrings as JSX props
I originally brought this up in https://github.com/mdx-js/mdx/issues/464#issuecomment-474018084 and again in https://github.com/system-ui/theme-ui/issues/212#issuecomment-516951612, where it was suggested that I open a new issue. Here’s the pitch:
Fenced code blocks should be able to specify “first-class” JSX props that get passed down to the MDX tag. Currently, everything after the language identifier is passed along via the metastring
prop, which is then passed as key/value strings, so this:
```js live foo=bar
```
…produces a remark code
node with properties: {live: true, foo: 'bar'}
, which is great! However, the key/value parser doesn’t support anything with strings, such as foo="bar baz"
. When you test this in the MDX playground:
```jsx live foo=1 bar="baz 2"
```
…it produces a node with properties: {live: true, foo: '1', bar": '"baz', '2"': true}
, which is clearly not right. Rather than inventing a new parser for this, I think it would be best to just treat the metastring as JSX props and either parse them “properly” (i.e. with Babel) at build time or inline them directly in the resulting JSX during the HAST → JSX compilation phase. For instance, I would expect the above example to compile to:
<MDXTag tag="pre" className="language-jsx" live foo={1} bar="baz 2" />
Or, to prevent breakage of existing components, pass them in via a separate prop:
<MDXTag tag="pre" className="language-jsx"
meta={{live: true, foo: '1', bar: 'baz 2'}} />
As a proof of concept, I’ve hacked together remark-fenced-props to show how at least the remark-level transformation of metastring
→ props
could work. It’s very much not production-ready or backward compatible with the key/value pair syntax, but it could easily be made so with a replacement like:
metastring.replace(/(\w+)=([^ ]+)/g, (_, key, value) => {
return isNaN(value) ? `${key}="${value}"` : `${key}={${value}}`
})
Anyway, lmk what you think!
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 12
- Comments: 20 (9 by maintainers)
I just ran into this and assumed (wrongly) that this was how it worked. I’d love to see this and would also be willing to do the above PR.
See the last comment when closing, this is closed because there is a solution to it already, I recommend https://github.com/remcohaszing/rehype-mdx-code-props!
Alright. I’ll play around a bit and open one if no progress results 😃
Thanks for the rapid responses. You’ve got an insanely massive body of work here.
This is now possible in the latest RC for MDX 2: https://v2.mdxjs.com. Specifically, it’s one line to use a plugin to do it: https://github.com/remcohaszing/remark-mdx-code-meta
It’s indeed a pretty weird key/value parser: splitting on spaces, then splitting on equals—not supporting quotes. Probably not how people expect it to be parsed.
@wooorm You’re absolutely right: for anything more complicated than 1-2 props, just dropping into JSX makes a ton of sense. I guess I just figured that it would be simpler on the MDX side to inline the metastring as props and just let the JSX parser throw syntax errors, rather than relying on a completely separate key/value parser. 🤷