Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DocumentContext not available inside _document when served by Fastly #16

Open
jonasthiesen opened this issue Feb 16, 2023 · 2 comments
Open

Comments

@jonasthiesen
Copy link

jonasthiesen commented Feb 16, 2023

The DocumentContext that is usually available is undefined when your page has getServerSideProps and is served by Fastly.

I have made a reproduction so you can see the behavior:
https://github.com/jonasthiesen/fastly-document-context-bug

@harmony7
Copy link
Member

harmony7 commented Mar 8, 2023

I have investigated this a bit and have figured out what’s going on.

It looks like Next.js is coded not to let Document be dynamic when it’s being run with NEXT_RUNTIME = 'edge'.

Something like this is hardcoded in the Next.js source code (next/packages/next/server/render.tsx):

      const documentElement = (htmlProps: any) => {
        if (process.env.NEXT_RUNTIME === 'edge') {
          return (Document as any)()
        } else {
          return <Document {...htmlProps} {...docProps} />
        }
      }

You can see see here that those htmlProps values are being thrown away.

The reason that in the repro the context appears to work when getServerSideProps() is removed is when that function is missing, then Next.js has all the information to render the page at build time, so it is no longer dynamic, and is instead rendered using SSG (server side generation). The output of the page is statically rendered into an html file, and in fact you’ll see the full output (including the rendered JSON of the context object) showing up in the /.next/server/pages/index.html file generated by next build.

Since this version of the next runtime emulates NextServer in the context of Compute@Edge JavaScript, an argument can be made that NEXT_RUNTIME = 'edge' is a bug. However this setting avoids the loading of a bunch of other modules that cause problems in Compute@Edge. This is something that may be possible to fix in the future but it will take some work.

@jonasthiesen
Copy link
Author

Thanks for looking into this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants