Markdown layouts don't act as nextjs "pages"

[loganpowell]

@jescalan Edit: in a markdown layout, you can't run getInitialProps or access the router since nextjs doesn't seem to recognize the layouts as page templates.

Hello again!

Loving the library and thank you again for the Windows fix. I hope I'm not being an air hog by creating another issue, but I hit another snag:

TypeError: Class constructor WithRouteWrapper cannot be invoked without 'new'
Module../layouts/FM-content.js
./layouts/FM-content.js:38
  35 | 
  36 | // Content.getInitialProps = async props => ({...props})
  37 | 
> 38 | export default withRouter(ContentLayout)()
View compiled
__webpack_require__
./webpack/bootstrap:21
  18 | // Execute the module function
  19 | var threw = true;
  20 | try {
> 21 | 	modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
     | ^  22 | 	threw = false;
  23 | } finally {
  24 | 	if(threw) delete installedModules[moduleId];
View compiled
Module../pages/about-the-law.mdx
/_next/development/server/static/development/pages/about-the-law.js:2173:111
__webpack_require__
./webpack/bootstrap:21
  18 | // Execute the module function
  19 | var threw = true;
  20 | try {
> 21 | 	modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
     | ^  22 | 	threw = false;
  23 | } finally {
  24 | 	if(threw) delete installedModules[moduleId];
View compiled
5
/_next/development/server/static/development/pages/about-the-law.js:2330:18
__webpack_require__
./webpack/bootstrap:21
  18 | // Execute the module function
  19 | var threw = true;
  20 | try {
> 21 | 	modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
     | ^  22 | 	threw = false;
  23 | } finally {
  24 | 	if(threw) delete installedModules[moduleId];
View compiled

I'm trying to use the withRouter wrapper with my Layout component. Is there a better way?

[Timer]

Sorry, but we really need a more detailed example.

[loganpowell]

for the time being, in this case:

const ContentLayout = FM => props => {
  ...
}

export default ContentLayout

I'll just use: FM.__resourcePath

[Timer]

@loganpowell Ooh! Sorry, totally clicked on this issue thinking it was the Next.js repository!

Don't mind me. 😄 Talk about droning through notifications. 😝

[loganpowell]

haha, no worries at all

[jescalan]

Hi, absolutely not - we're very actively working on this one and want to make sure it works as expected. I'm not sure I understand exactly what your use case is here though - would be happy to jump on a call if you'd like to go through it, or if you have a minimal reproduction we can pull it down and narrow down what's going on.

[loganpowell]

Thank you for your patience :)

I'm just trying to wrap a layout with withRouter from next/router and get the props provided thereby (e.g., props.router.route), but then I get this error when I try to do that with a layout used by next-mdx-enhanced via the layouts:<this layout> in the frontmatter.

I can try to reproduce a minimal example, but I'm under a deadline and just using the initial props.__resourcePath within the props of the exported layout works for my use case. I believe that it's because props are being passed to a higher order function via next-mdx-enhanced which then calls the underlying React component, whereas - with next/router just spreads the props together with the underlying component.

[jescalan]

Got it, will look into this a bit. I think it's got something to do with the way mdx does layouts - I have been unable to get getInitialProps running on mdx layouts despite them apparently being top level. Because of this I'm not sure that the mdx layouts are being seen as pages components. I think the __resourcePath solution is a great one for now - this issue is definitely on my radar, when we have something to report will do so here!

[loganpowell]

Thank you again for the great library and help!

[jescalan]

Going to rename and reopen this, because it is a thing we want to address soon, an active issue, and we will reference this issue and close once its been addressed 😀

[jescalan]

Ok I am blocked by this on one of our projects now, so will have a resolution soon

[loganpowell]

I'm sorry to hear that, but great!

[jescalan]

Ok small update here - I have a workaround for this that's quite effective, but it's not a smooth as I'd like the ultimate fix to be. This is already an open issue in mdx though, so it looks like its being worked on.

At some point I'd like to put out a smoother fix that basically requires zero config changes at all, but for now this interim solution works quite well so I want to post here for anyone else running into the issue: mdx-js/mdx#382 (comment)