props key returns empty object from scope

[mattboon]

Hi there

Have found that using the props key in next-mdx-remote's scope property always returns an empty object

See this example:
https://codesandbox.io/s/next-mdx-remote-props-s85i4?file=/pages/index.js

props.title returns undefined, but props2.title returns as expected. props does however return an empty object.
Could there be something overwriting it somewhere in MDX, or is it somehow a reserved word?

Would ideally like to use the props. notation in MDX pages as it's familiar from the React ecosystem.

Any help appreciated. Thanks

[BRKalow]

Good find! From what I can see, with the way the the mdx library is building up the component (reference), we'll have to treat scope.props differently, as injecting props into the scope as we are now understandably conflicts with the local props reference generated by mdx itself.

Effectively what we are doing here is wrapping the result of running mdx in a function to create the scope:

fn (props, props2) {
  return function MDXContent(props) {
    // local props would shadow props from scope
  }
}

I'll do some thinking on a sustainable way to accomplish this. Feel free to contribute if you've got something in mind!

[rfrowe]

@BRKalow I've just run into this issue. I have to admit I was quite perplexed when only the props key didn't work. I'm forced to use this codepath with my setup. I'll noodle on this and get back to you with some ideas.

[rfrowe]

Okay I've done a bit of poking around and I came up with a solution that works, though you may not like it. To bypass the shadowing issue, I think we can simply use the props that are passed to MDXContent. I think this intuitively makes sense since we are trying to pass props to the component, so we may as well use the front door rather than the window. For example, if we change the hydration from src/index.tsx:

@@ -70,10 +70,11 @@ export function MDXRemote({
     // if we're ready to render, we can assemble the component tree and let React do its thing
     // first we set up the scope which has to include the mdx custom
     // create element function as well as any components we're using
+    const {props = {}, ...remainingScope} = scope
     const fullScope = Object.assign(
       { opts: { ...mdx, ...runtime } },
       { frontmatter },
-      scope
+      remainingScope
     )
     const keys = Object.keys(fullScope)
     const values = Object.values(fullScope)
@@ -88,7 +89,8 @@ export function MDXRemote({
       keys.concat(`${compiledSource}`)
     )

-    return hydrateFn.apply(hydrateFn, values).default
+    const Component = hydrateFn.apply(hydrateFn, values).default
+    return () => <Component {...props} />
   }, [scope, compiledSource])

   if (!isReadyToRender) {

This will extract any props from scope and inject them into the MDX component via the traditional route. I tested this as a hack via my browser debugger but I'll look into forking this and testing it as a full-fledged change. I think in reality it may make more sense to add a props: P field to MDXRemoteProps<P> and add type parameter <P = {}> to MDXRemote.

[BRKalow]

@rfrowe Sorry for the delay. If you're still interested, feel free to open a PR with this and we can take a further look!

[rfrowe]

@BRKalow I've opened a PR for this, please take a look.

[talatkuyuk]

No need to make any change in the package, the issue comes from the way of implementation.

You can use like props.foo expression in the mdx file by using a recma plugin depicted below.

See mdx-js/mdx#2437

Therecma plugin is recma-mdx-change-props for the issue.