Does serialize() (next-mdx-remote) and evaluate() are compatible for the same MDX source?

[sync-adm]

Hello, there.

Briefly, I have an editor that builds an MDX file composed of components like blocks.

I'm using 2 "different" libraries to render my mdx at different times, when editing I use evaluate from @mdx-js/mdx(only to show a preview on client-side) and when generating static pages I use next-mdx- remote.

The MDX that is generated by the editor looks like this:

When I use an evaluate here it works, as a "props" property is expected.

But when I try to generate static pages from that same MDX with next-mdx-remote, it breaks when I pass the "props" property, since it was not expecting such a property like evalute.

And this is the MDX that works on MDX remote:

Note that this requires passing a "frontmatter" property

The only solution I found was to convert the MDX file to string and rename everything that is "props" to "frontmatter" in it, but that doesn't smell right. That's why I came here to ask for a direction.

I would like to know if the same MDX file could be valid for this 2 methods in this 2 libraries, or if it is possible to configure such a thing? Am I missing something?

Here is a reproduction, stringMDX has to be different:
MDX EVALUATE: https://github.com/marissync/mdx-poc/blob/main/pages/evaluate-test.tsx
MDX NEXT-MDX-REMOTE: https://github.com/marissync/mdx-poc/blob/main/pages/mdx-remote-test.tsx

Relevant Information:
Next JS APP

Relevante Libs:
"@mdx-js/mdx": "^2.3.0",
"@mdx-js/react": "^2.3.0",
"next-mdx-remote": "^4.4.1",
"remark-frontmatter": "^4.0.1",

[wooorm]

I am not sure. I don’t maintain next-mdx-remote. That being said, I think one can assume that there are differences.

There are some weird things going on in your example. For example, your MDX file contains frontmatter. But that frontmatter isn’t used.
You instead pass props that look very similar to evaluate: https://github.com/marissync/mdx-poc/blob/9aeeb3aab40234cbd5d063e96e344f0439ac96bf/pages/evaluate-test.tsx#L28, https://github.com/marissync/mdx-poc/blob/9aeeb3aab40234cbd5d063e96e344f0439ac96bf/pages/evaluate-test.tsx#L32.
But there are no props to next-mdx-remote: https://github.com/marissync/mdx-poc/blob/9aeeb3aab40234cbd5d063e96e344f0439ac96bf/pages/mdx-remote-test.tsx.

So I think it is logical to conclude that if you pass different props to different libraries, they will do different things.

The only solution I found was to convert the MDX file to string and rename everything that is "props" to "frontmatter" in it, but that doesn't smell right. That's why I came here to ask for a direction.

What is your actual problem? What is your actual question? What do you want to do?
Do you want to use frontmatter? Do you want to pass props? Why would you even want to use two tools that do the same thing?

[sync-adm]

Thanks for replying @wooorm.

In the example I didn't extract the front matter from the MDX just to keep it simple.

In fact, in the code I'm building is something like this #2220, the content of "props" is extracted from the frontmatter which is part of the MDX.

What is your actual problem? What is your actual question? What do you want to do?

I would like to have some sort of compatibility between those two libraries with the same MDX file. In my case this might work if the MDXContent "props" key could be changed to another key name like "frontmatter". Is that possible? if yes, how to do it?

Do you want to use frontmatter?

Yes, I need frontmatter.

Do you want to pass props?

Yes, I need to pass the "props". Is there another way to do this?

Why would you even want to use two tools that do the same thing?

mdx-js/mdx together with other plugins works on handling the AST and creating the MDX, as well as rendering it in the editor (with evaluate) which is done on the client side. The final product is a website that needs to be lighter and the compilation process to be done on the server-side, something I didn't manage to do with Next.Js and "evaluate".

[wooorm]

If you want frontmatter, see the frontmatter section on the website: https://mdxjs.com/guides/frontmatter/.
It explains what to do. Particularly the last sentence.

[…] something I didn't manage to do with Next.Js and "evaluate".

Then that’s your question. See the guide on using MDX on demand: https://mdxjs.com/guides/mdx-on-demand/. You compile on one side. You send it over the wire. You run on the other side. Same as next-mdx-remote.

[sync-adm]

@wooorm,

Thank you very much for the support.

I was confusing the concepts. At one point there was even an incompatibility between mdx-remote and mdx-js.

If it's useful, here's a link to an Mdx containing a custom component running on demand.

Visível só para você

[wooorm]

Well that’s visible to me ;)

Cool! Glad it worked!