Is scope still supported in MDXv2? If not, what's its replacement when runtime rendering is desired?

[godmar]

I have been using @mdx-js/runtime and the scope attribute as discussed here and corrected here.
I have read the v2 migration guide (also here) and would like to upgrade to v2.

How do I pass additional variables into the MDX scope in v2 when using evaluate/evaluateSync to replace @mdx-js/runtime as suggested in the transition guide?

Note: when rendering the MDX as part of an integration, I can work around the issue by directly importing it, e.g.

import config from '/config/config'
....

However, when I render the same MDX using evaluate (which will be on the client), the import statements won't work. My code strips them, but then config is undefined unless I provide it via the scope, which in v2 seems to not work when using the changes suggested in the migration guide (and also in this post).

Let me describe my use case (to make sure what I'm trying to achieve is actually possible).
I'm using next.js's mdx integration, so I have under /pages files like /pages/about.mdx etc. These files include import statements and they have an export statement at the end, just described in the next.js guide here. This all works, and I am creating a site using next.js's export feature that I statically host. I do not use SSR in response to individual requests.

Now comes the dynamic part: when the client loads the site, they make an API request to find out if any of the .mdx content has changed. If not, nothing needs to be done, the server-side rendered content is being displayed. If so, it'll fetch the updated .mdx file directly and I would like to evaluate it on the client using MDX's evaluate feature. This is when I strip the import statements and would like to provide the components (and data in the scope) instead via the components= and what was in MDXv1 the scope= properties.

The rationale behind this is the following: rebuilding the website takes several minutes due running next build, next export, etc. However, sometimes I'd like to be able to publish minor updates to my MDX content immediately, just by changing the .mdx file (the way you could update web pages in the 1990's...). The expense of using MDX's runtime would thus only be paid until the site is rebuilt, at which point the new version of the mdx would be baked again into the build.

Is my use case too much outside of what MDXv2 was designed for?

[wooorm]

Hey! You can pass props instead: https://mdxjs.com/docs/using-mdx/#props.

---

It sounds like you’re regexing imports away, that sounds dangerous and error prone. Imports are supported client side by, I believe, all browsers.

For your use case, you should likely do something along the lines of what’s described in the MDX on demand guide.

You should be able to change an MDX file locally, push changes, and Next takes care of deploying your site?

[godmar]

Thank you for your reply!

First, regarding the use of props - you're right, that makes sense - however, this works only if I render it at runtime, it doesn't work when rendering via the next.js integration - is this correct? Otherwise, how do I pass props to a mdx page when it is rendered as part of the integration, such as when /pages/about.mdx is being rendered? As such, it would require 2 versions of the mdx - one that's used for the integration, and one for dynamic updates.

Second, you are correct that I am regexing the import away, which is brittle. I'd prefer not to. Come to think of it, if I don't use imports and instead rely on MDXProviders to bring in all components, I might not need any import statements at all.

When you say that imports are supported client-side, let me make sure I follow. You're suggesting to allow dynamic imports, somehow, and then the client would fetch the .js file via an import basepath and that would then work? But the file that's being fetched is one that's normally subject to webpack processing (I guess in this case it would be regular JS only.) I haven't tried and am also a bit loathe to try it as it would basically mean that clients directly refer to other files in the codebase, so I'd need to deploy those somehow. But I may try it.

Lastly, regarding the suggestion of using MDX on demand or next-mdx-remote, I believe that this relies on having a next.js server running, which I do not do. The use of getStaticProps is not compatible with next export to my knowledge. I also don't know/don't believe that next export would support incremental deployment of changed or new mdx files.

Meanwhile, I've come up with another idea (that seems to work for both scenarios, actually).
To avoid having to include objects into the scope, I could expose an object's properties, say config, using a wrapper component Config provided by MDXProvider:

components = {
   ...
   Config: ObjectComponent(config)
}

which is defined like so:

// src/ObjectComponent.js
import React from 'react';

export default (obj) => (props) => {
    const allprops = Object.keys(props).map((k) => obj[k]).join(" ");
    return <>{allprops}</>
}

Then I can use <Config fullname /> to access, e.g., config.fullname.
This would work via the MDXProvider and not require adding things to the scope (or props) for runtime rendering.

[wooorm]

Next.js is different I believe indeed. They don‘t let you call MDXContent yourself (or any page for that matter). But some props are being passed, right? You’re passing components, so you are passing some props. Maybe you can get Next.js to pass other props, too. But that’s on Next.

When you say that imports are supported client-side, let me make sure I follow.

Indeed, I mean that JavaScript in Node.js and all modern browsers supports imports. Of course, when you are using a tools that prevent you from using imports, it doesn’t work anymore.

next export

It sounds like you’re rebuilding Next.js without Next.js — that you’re making everything extremely hard. Next.js solves the things you want to do already. I strongly recommend either using Next.js when you want the things you want (dynamic, updating), or don‘t try to implement them when you don’t use Next.js

[godmar]

Thanks for the reply.

It is indeed difficult for me to choose the right design among the many possible. So far, my rationale for not using Next's on-demand, per request SSR has been to not wanting to have a slow node.js server in the loop for every request (*). Instead, I wanted a more traditional design where static assets are prebuilt, put in the filesystem, and then are served by nginx/Apache and all dynamic content is fetched via a JSON/REST API separately. However, I also wanted SEO, which is why I brought in next.js and its server-side rendering capabilities in the first place. The only way to marry both requirements is to use next export where next performs a single SSR pass and saves the results in .html files.

Your advice is sound, though. Perhaps I shouldn't try to make the frameworks do things they weren't designed for.

(*) in addition, my hosting provider supports only Apache/Nginx + a single API route. At this point, at least.

[godmar]

So, I think I got it actually working with your help in the issue regarding wrappers.

My MDXProvider in /pages/_app.js does:

  wrapper: (props) => {
    const router = useRouter();
    let mdx = router.asPath;
    if (mdx == '/') mdx = '/index'
    mdx = `pages${mdx}.mdx`;
    return <HotUpdateAbleMDX src={mdx}>{props.children}</HotUpdateAbleMDX>;
  }

HotUpdateAbleMDX is my wrapper:

export function HotUpdateAbleMDX({ children, ...props }) {
  return (
    <MainTemplate>
      <StyledContainer maxWidth="xl">
        <HotUpdate {...props}>
          {children}
        </HotUpdate>
      </StyledContainer>
    </MainTemplate>
  );
}

and HotUpdate does:

const components = {
    wrapper: ({children}) => (<>{children}</>),
}

export function HotUpdate(props) {
  const [mdx, setMdx] = useState("loading updated mdx, please be patient....");
  const [newVersion, setNewVersion] = useState(false);
  const src = props.src;
  useEffect(() => {
    let fetchit = async () => {
      // fetch new mdx and call setMdx(data);
    };
    TimeStampManagerFactory().then((timestampemanager) => {
      if (!timestampemanager.isUpToDate(src)) {
        setNewVersion(true)
        fetchit();
      }
    });
  }, [])

  if (newVersion) {
    const {default: Content} = evaluateSync(mdx, {...mdx_react_provider, ...jsx_runtime})
    return (<MDXProvider components={components}>
              <Content />
            </MDXProvider>);
  } else {
    return (<>{props.children}</>);
  }
}

The time stamp manager checks if the API reports a newer modification time for the .mdx on the server.
This works with next export (I can read the file with lynx).

Of course, I can't use imports in the .mdx files but I think I can live with that for now.