vercel / next.js

The React Framework
https://nextjs.org
MIT License
124.49k stars 26.58k forks source link

Undesirable custom error page behaviour (output + re-fetching data client-side) #47978

Closed tills13 closed 6 months ago

tills13 commented 1 year ago

Verify canary release

Provide environment information

Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP Fri Jan 27 02:56:13 UTC 2023
    Binaries:
      Node: 16.20.0
      npm: 8.19.4
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.2.5-canary.30
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

Data fetching (gS(S)P, getInitialProps)

Link to the code that reproduces this issue

https://github.com/tills13/nextjs-error-behaviour-reproduction

To Reproduce

  1. pull repo
  2. configure node / npm (I have provided a .nvmrc)
  3. run NODE_ENV=production npx next build && npx next start
  4. navigate to /
  5. view HTML flashing, console output

Describe the Bug

  1. undesirable console output in production

image

  1. error page re-runs getIntialProps client-side on the initial render resulting in a mismatch between server HTML and client HTML. This behaviour is different from other pages. Additionally, the err received by gIP client-side is different from the error received server-side. I recognize that it cannot be the same instance / class / whatever due to it needing to be serialized. This is more of a nit than anything as the desirable solution would be to just not re-run gIP client-side (see Expected Behaviour) Re-running gIP client-side also means that long running getInitialProps prevents JavaScript from running client-side until getInitialProps resolves. I have left some commented code in _error to demonstrate this.

Expected Behavior

  1. no output in the console. If I need console output to instruct users in production, I will do it myself.
  2. ideally the error page would not re-run getIntialProps client-side for a server-side error. I'm not too upset about this as our app gIP is fast, but it can result in the server HTML flashing before the client HTML settles.

Which browser are you using? (if relevant)

Chrome

How are you deploying your application? (if relevant)

next start

TasukuUno commented 1 year ago

Hi, thank you for the issue. I've faced the same problem... In my case, it does not occur up to 12.2.1-canary.3, but it does occur from 12.2.1-canary.4 onwards. Is there a workaround for this issue at the moment?

tills13 commented 1 year ago

@TasukuUno you could check out the attached PR for a solution.

tills13 commented 1 year ago

Ah, sorry, just noticed 12.x. The PR is for 13. I'm not sure how much that file has changed but you might be able to apply the same fix on 12.

TasukuUno commented 1 year ago

@tills13 Thank you for your response! What I want to know is whether end-users like me can do something to avoid this behavior in the latest version. Is our only option to wait for your PR to be merged? As far as I can see, there are no workarounds...

github-actions[bot] commented 6 months ago

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.