[idea] Parse fenced code block metastrings as JSX props

[shawnbot]

I originally brought this up in #464 (comment) and again in system-ui/theme-ui#212 (comment), 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!

[RichiCoder1]

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.

[wooorm]

👋

Would this need to support expressions? Spread assignment expressions? Such as:

```js {...object} key={<h2>asdasd</h2>}
```

[shawnbot]

Would this need to support expressions? Spread assignment expressions? Such as:

IMO, yes. At the very least, that would mean not having to introduce some new/different syntax from the one you're using in the document already.

[wooorm]

Right, makes sense! Having JSX attributes instead of some other form of attributes too. I am worried that we’re adding another way to do things. Yes, this is nice:

```js live foo={1} bar="baz 2" {...object} key={<h2>asdasd</h2>}
console.log(1)
```

But you can already author as (or am I missing something? Do you need to get the <pre>/<code>?):

<MyCode live foo={1} bar="baz 2" {...object} key={<h2>asdasd</h2>}>

  ```js
  console.log(1)
  ```

</MyCode>

Meta string is a weird and intriguing thing! It’s the “hidden” place in Markdown.

[shawnbot]

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

[wooorm]

rather than relying on a completely separate key/value parser. 🤷

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.

[KutnerUri]

This is needed.
For example, I am trying to make the same 'live' preview, and I need to pass the scope to the Code component:

import { Button } from 'my-button'
const scope = { Button };

Try out this button!
    ```tsx live scope={scope}
    <Button>click me!</Button>
    ```

This is not possible with today's parser.

[wooorm]

@KutnerUri You can use a component for that now.

<MyComponent language="tsx" live scope={scope}>
   {"<Button>click me!</Button>"}
</MyComponent>

[KutnerUri]

@wooorm I know, just wanted to upvote, and add another use-case.

I'm using MDX to document components, and I would like the document to be portable, i.e. every MDX reader would be able to render its own live playground with it's own styles.

It would be nice to get the component from context, but it doesn't seem to be working

import { Button } from 'my-button';

<components.Code scope={{ button }}>
   {"<Button>click me!</Button>"}
</components.Code>

[wooorm]

Replacing components.Code with Code in that file, assuming Code is passed into components somewhere, might currently work.

[prichey]

@johno @wooorm As a stopgap, what would you think about using jsdom to do something like:

const dom = new JSDOM(`<!DOCTYPE html><div ${metastring} />`);

then just parsing the attributes off of that? It wouldn't work for objects, functions, etc., but IMO supporting quoted props would make this much more useful than just splitting on spaces.

[prichey]

Realizing now this could be done with the underlying parse5 rather than the full jsdom package. If you'd entertain a PR with this implementation, I'd be happy to submit one!

[wooorm]

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

[didaktio]

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

For some reason I cannot get this to work. Is there a working example somewhere using @mdx-js/mdx, either compile or evaluate?

[wooorm]

The example in the readme but changing xdm to @mdx-js/mdx should do the trick.

[didaktio]

The example in the readme but changing xdm to @mdx-js/mdx should do the trick.

For some reason, not. I think the problem is coming from that fact I am using remark-rehype, which is stripping everything but classname from code blocks beginning with three backticks.

For example:

Given MDX

With

Means the plugin has not effect. Swapping the order gives the output where HTML is a string. But of course I want JSX.

I'm doing something wrong here but cannot see what. I know getting low-level with unified etc is an option but it's one I'd like to avoid given the beauty of MDX v2.

Maybe the problem is that I shouldn't need to use remark-rehype, but I'm getting 'cannot compile node x' errors if I do not. I read that MDX supports basic markdown things like headings by default, but evaluate (at least) doesn't seem to.

[wooorm]

I think the problem is coming from that fact I am using remark-rehype,

...right... you shouldn’t use remark-rehype. That’s not in the example. And it’s not going to work.

but I'm getting 'cannot compile node x' errors if I do not

You shouldn’t

I read that MDX supports basic markdown things like headings by default, but evaluate (at least) doesn't seem to.

It does.
I think you should open a question with a reproduction of your original problem!

[didaktio]

It does. I think you should open a question with a reproduction of your original problem!

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.