Maybe get rid of double-brace syntax?

[Xiphe]

Hey I just stumbled upon this and am using markdown-it-jsx at the moment.

How are your thoughts about the double brace syntax?
I'd really like to use native JSX without any extra syntax within markdown.
Would you be interested in PRs in that direction?

[ticky]

The double brace syntax was an intentional trade-off as I explicitly need to allow interpolations within code blocks, some of which may contain code using such braces, and short of rewriting markdown-it to handle complex new escaping rules, this was the only way to do it.

If there’s a reasonable way to accomplish both, I’d definitely be interested, though I feel that disambiguation is important.

[ticky]

There are two important parts of the parser tests which are relevant to this;

• a snippet of Bash which defines a function containing an interpolation, and the relevant snapshot
• a snippet of Bash which defines a function alongside an interpolation, and the relevant snapshot

Both of these should be able to be accomplished.

[Xiphe]

Hey @ticky, thanks for the response.

I see now. From what I understand your approach is to have double-braces be evaluated before any other markdown syntax is parsed, right?

My Idea is more to replace native HTML within markdown with native JSX.

What we could do is simply combine these approaches.

1. parse all {{ myVar }} double-braces
2. parse rest of markdown (allowing jsx)
3. evaluate as jsx

This would keep your usecase while allowing mine, too.

example.mdx

Hello World
========

```php
echo "{{ props.greeting }}";
```

<Greeter suffix="1">World</Greeter>

```jsx
<Greeter suffix="1">World</Greeter>
```

Other Ideas would be to make the markdown parser of this project customizable or I could just go with a specific loader for my usecase markdown-it-jsx-loader.

[ticky]

Yeah, currently it pulls out double-brace interpolations, replaces them with the sha256 of their content, processes markdown, then puts them back.

Your example.mdx is a bit unclear; would you intend that both <Greeter />s get evaluated as JSX, only one, or neither?

I’ve actually got a WIP PR up (#8) which would address this - I realised that I had some partially-done code sitting on my computer from November (oops!) which I just polished up to push up there. It needs specs updated (likely just with some self-closers and examples of both HTML and React inclusions) and it should be good to go - feel free to target a PR at it if you wanna get it finished up! 😄

In terms of customisation, I’ve added the ability to use MarkdownIt plugins natively, but I’ve not yet gotten around to allowing customisation of other MarkdownIt options. I’d welcome a PR for that too, though obviously there are a few bits of MarkdownIt behaviour which are mandatory for this loader to function, so I’d not bother to expose those!

[Xiphe]

sweet, i'll look into that.

in my example.mdx, the first <Greeter /> would be evaluated, the second will be rendered as

<pre><code>&lt;Greeter /&gt;</code></pre>

[ticky]

I had another look at this, and it looks like that branch actually has some inconsistencies (which is probably why it didn’t get published at the time!) I’ll update the spec suite with my rough expectations!

Sorry, turns out that’s kinda difficult with this snapshot thing, haha. I’ve updated the spec suite to be a little easier to hook into, though!

[ticky]

I’ve had another look at this and I think it’s most of the way there. If you wanna experiment with that branch and see how it feels, feel free.

I’ve gone with a kinda nasty hack to make MarkdownIt properly handle JSX tags, I notice that markdown-it-jsx uses its own parser, but I kinda wanna void bringing such a thing in. The stuff it’s monkeypatching hasn’t changed in two years, but this feels potentially flaky.

[davidtheclark]

Looking at PR #8, it seems to me like avoiding an interpolation delimiter (currently the double-curly-braces) might be more trouble than it's worth.

If I'm understanding this module correctly, the simplest approach to transforming md-with-JSX to JSX might break down to these steps:

1. Remove all JS/JSX interpolations, replacing them with placeholders that are parseable within Markdown. (This way markdown-it doesn't have to deal with JSX at all, in any way.)
2. Parse the Markdown into HTML.
3. Convert the HTML to JSX.
4. Restore the JS/JSX interpolations (in a way that works within JSX).

The first step is key, and it should be pretty straightforward if the delimiter syntax is easy to find, weird enough that it won't clash with Markdown prose, and also won't clash with the JS/JSX it wraps. Trying to parse out JSX elements, determining where they start and end, will be harder and more flaky than searching for non-clashing delimiters; and hacking into markdown-it is definitely sketchy, as you say @ticky.

Accomplishing that first task should be super straightforward if the delimiter syntax does not clash with JS/JSX. Are there problems with the double-curly-braces clashing with JS/JSX, or is it already implemented in a way that works just fine?

If it has been clashing, and that's part of the impetus for this issue, it might be worth considering a different delimiter syntax that would not clash with JS/JSX (<% ... %>, for example, which has been established with Lodash templates).

[ticky]

It’s been a while since I was directly working on this, so forgive me if this isn’t completely accurate or I’ve missed something, but, in summary, yeah. Removing all the JSX-like items from the stuff we send to the JSX parser is necessary for this to work.

The double-brace thing works except for the fact that double handling was necessary to make it not clash with objects in JSX props.

I believe the solution would be to;

1. Adapt 🚪 Allow plain JSX in Markdown, handle self-closing tags #8’s HTML walker to be able to walk (read: ignore the contents of, see step 2) markdown code blocks as well
2. When encountering a JSX opening tag, if we’re not in a markdown code block, replace the entire tag with the hash of its name and props
3. When encountering a JSX closing tag, replace the tag with the hash in step 2
4. Replace those hashes with the original contents after converting the markdown to JSX

I believe the double-brace syntax is fine, however, I believe I applied them to more situations than were necessary and this caused unnecessary issues (this is also why text is wrapped in JSX assignment expressions in the output - this shouldn’t truly be necessary, I believe).

My goals remain;

1. Allowing use of JSX-like assignment expressions anywhere - in prose, in code blocks, and in particular in code which might look like HTML or JSX
2. Allow the use of JSX elements anywhere - with no interpolation necessary when outside a code block, and with some other syntax when inside a code block

The double-brace syntax might have been a poor choice given the extra handling it has required, but if it can be kept, I would prefer that!

[ticky]

I believe generalising the process-html routine would allow this to be accomplished pretty simply.

I should be able to devote some time to this in the next few days!