docs(mdx): add a dynamic imports section for App Router

[samcx]

Why?

Adding a section dedicated to dynamically importing MDX files inside pages for App Router.

• x-ref: Docs: Clarify that first-party `@next/mdx` also has dynamic `import()` - not just `next-mdx-remote` #70417

[samcx]

• docs(mdx): add a dynamic imports section for App Router #73466 👈 (View in Graphite)
• canary

This stack of pull requests is managed by Graphite. Learn more about stacking.

[samcx]

cc @karlhorky I don't think this is as seamless (probably possible) with Pages Router since pages can't be async in Pages Router, so opted to just stick to adding this for App Router.

[karlhorky]

I would suggest removing / reworking the "Remote MDX" section, at least for App Router:

• https://github.com/vercel/next.js/blob/sam/docs/mdx-dynamic-imports/docs/01-app/02-building-your-application/07-configuring/05-mdx.mdx#remote-mdx

This section introduces secondary terminology "remote MDX" and recommends a 3rd-party library, whereas these capabilities are possible with only @next/mdx

[samcx]

@karlhorky I'm not sure if this is the same capabilities—the Remote MDX example is using raw Markdown text from fetch, whereas my example is importing a markdown file as a Component.

We could probably figure out a way to fetch Markdown text and make it usable, but it seems more complicated to implement than just <MDXRemote source={markdown} />.

Maybe we just remove this line from the Remote MDX section → " content stored in a separate local folder"?

[karlhorky]

I'm not sure if this is the same capabilities—the Remote MDX example is using raw Markdown text, whereas my example is importing a markdown file as a Component. If we fetched MDX text, how would we pa

With this part "If we fetched MDX text, how would we pa", I guess you mean "how would we parse and compile the MDX"

Maybe @next/mdx won't completely take over all capabilities of next-mdx-remote, but maybe your next comment also has a suggestion of how to deal with that:

Oh I guess we have this section → nextjs.org/docs/app/building-your-application/configuring/mdx#deep-dive-how-do-you-transform-markdown-into-html

That's a good point, we could potentially suggest that.

Maybe we just remove this line from the Remote MDX section → " content stored in a separate local folder"?

In case you think there's a high value of keeping the "Remote MDX" section, this would also be a possibility:

Eg. remove the parts about local files, which overlap with @next/mdx capabilities with await import().

Maybe also add more language about this being an "alternative" and more emphasis that it's "third party". Could also be moved further down in the docs.

[samcx]

@karlhorky Sounds good! It's late here (the next day haha) so I will finish later today!

[karlhorky]

Also, if the following people have time, would also request a PR review from you as well:

• @wooorm
• @remcohaszing
• @wesbos
• @pomber

[remcohaszing]

<MDXRemote source={markdown} />

This looks suspicious. markdown is a string. Is the source markdown or MDX? Usually this is inferred from the file name, defaulting to MDX. But no file name is given here and the variable is named markdown.

[wesbos]

couple clarifications needed as you can run into issues here

[samcx]

<MDXRemote source={markdown} />

This looks suspicious. markdown is a string. Is the source markdown or MDX? Usually this is inferred from the file name, defaulting to MDX. But no file name is given here and the variable is named markdown.

@remcohaszing I think markdown is actually correct → https://github.com/hashicorp/next-mdx-remote?tab=readme-ov-file#react-server-components-rsc--nextjs-app-directory-support

Addressed

[karlhorky]

Thanks everyone for getting this in! 🚀