Working around the removal of layoutProps

[juice49]

In MDX 2, layoutProps have been removed. Values exported by the MDX document are no longer provided to the layout component.

If you import an MDX document directly, you can work around this by importing the values you need (as described in the MDX 2 migration guide). But in other scenarios (for example, using MDX documents with the Next.js filesystem router), the MDX document is never directly imported by the user. I haven't yet figured out how to work around this—if I don't explicitly import the MDX document, I can no longer access its exports in the layout.

I tried using a [slug].tsx page to workaround the issue, inside which the Next.js getStaticProps function dynamically imports the appropriate MDX document; but this doesn't work because the MDX component cannot be serialised to JSON (which is a requirement of props returned by getStaticProps).

I'm still trying to figure out other ways around this issue, but how is everybody else doing it?

[wooorm]

Is getStaticProps needed? Is it needed to send a component as a static prop?

[juice49]

As I understand it, yes. Something needs to run on the server to import the MDX document based on the requested slug. I explored a few ways to do this, but they all seem to have caveats.

MDX on demand

Note: MDX is not a bundler (esbuild, webpack, and Rollup are bundlers): you can’t import other code from the server within the string of MDX and get a nicely minified bundle out.

next-mdx-remote

next-mdx-remote provides a tool for serialising the MDX component, and next-mdx-remote@next supports MDX 2. But it does not support imports or exports from the MDX document.

Next.js dynamic import

This seemed promising, but in order to dynamically import React components we have to use next/dynamic to handle the import.

The problem here is:

The path must be explicitly written. It can't be a template string nor a variable. 

...which means we cannot use next/dynamic to import the MDX document based on the requested slug.

[wooorm]

That you now share that you want to split work between clients and servers, gives different insights into your question.
Perhaps you can more broadly expand on your question instead of making it super specific (see https://mdxjs.com/community/support/)?

[juice49]

Thank you for your help on this issue. The main problem is that the Next.js documentation for using MDX is not compatible with MDX 2. The documentation shows exported values being used in the layout component, and I don't think there's a migration path for this usage. Because layoutProps are part of the Next.js docs, I imagine many others are also relying on it and will run into this issue when migrating to MDX 2.

[juice49]

I think I've stumbled upon an interesting work around. MDX documents can export a getStaticProps function just like any other Next.js page. Page props can be used in a similar way to layoutProps in MDX 1. We can add a getStaticProps function to the MDX document that returns values we want to expose as Next.js page props.

To make this smoother, I created a function to modify the AST and automatically add a getStaticProps function based on a mapping provided by the user. This means:

• MDX documents can still export values that we can import directly.
• These exports can also be exposed to Next.js (e.g. in the pageProps prop passed to _app.tsx).

Here's my first attempt. 🚨 Not fully tested; just thrown together as a proof of concept:

import { parse } from 'acorn'

/**
 * AST transformer adds `getStaticProps` to the tree based on provided mapping.
 */
function createNextStaticProps(map) {
  return function transformer(tree) {
    tree.children.push({
      type: 'mdxjsEsm',
      data: {
        estree: parse(
          `
          export const getStaticProps = async () => {
            return {
              props: ${map},
            }
          }`,
          {
            sourceType: 'module',
          },
        ),
      },
    })
  }
}

Include the transformer in MDX options:

import withToc from '@stefanprobst/rehype-extract-toc'
import withTocExport from '@stefanprobst/rehype-extract-toc/mdx'

// ...

{
  rehypePlugins: [
    withToc,
    withTocExport,
    [
      createNextStaticProps,
      `{
        meta,
        tableOfContents,
      }`,
    ],
  ],
}

Now, the exports meta and tableOfContents are passed to the Next.js pageProps. tableOfContents is generated by @stefanprobst/rehype-extract-toc/mdx, and meta is exported manually just like before. The neat thing is we can either import them directly, or access them via pageProps in _app.tsx.

export const meta = {
  title: 'JSON Feed Types',
  description: `I've been working on adding JSON Feed to my blog, but I was surprised to discover that nobody has published JSON Feed TypeScript types yet. So I made some.`,
  date: '2021-10-01',
  tags: ['JSON Feed', 'TypeScript'],
}

I've been working on adding [JSON Feed](https://www.jsonfeed.org) to my blog.

[wooorm]

Good, so Next.js takes getStaticProps and passes those props to the page component when it calls it!

For your code, I have the following review/suggestions/nit/tips/ideas:

• I recommend sticking with package names (rehypeExtractName) instead of a custom name (withSomething)
• getStaticProps doesn’t have to be async in this case
• build an actual AST instead of using atom.parse each time, it’s faster to build an AST, and using acorn.Parse introduces some bugs (particularly around positional info and when injecting strings into strings). See https://astexplorer.net for more info.
• You can visit the AST and use periscopic to figure out what identifiers are in scope, and thus which are exported. You could use this information to prevent errors (e.g., when a certain file does not export a meta, it currently crashes). You could also use this information to generate the list of identifiers to export

[juice49]

Thank you so much for the thoughtful review. I'm new to working with Unified and ASTs, so it's incredibly useful. I'll fix up the code accordingly 🙂.