props key returns empty object from scope

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

[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.

[rfrowe]

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