Client error handler should not run on initial render

[bryanrsmith]

I have a site that only supports modern browsers. Old browsers can still access the content thanks to server rendering, which is great. The problem is that Next currently renders an error page when an exception is thrown during render.

So, in an old browser:

1. Navigate to the site
2. Server renders the page
3. Client displays the server-rendered page
4. Client runs the client script. The page component uses an API like Object.assign, causing an exception to be thrown in the old browser.
5. Next switches to the error view, hiding the original content.

My preference would be for Next to ignore exceptions during the initial page load so that old browsers will continue displaying the server-rendered content. I can work around this by loading polyfills (that I don't need for my target users), but it'd be nice if I could avoid this.

FWIW, I ran into this because Googlebot apparently runs a very old version of Chrome, and was seeing the error page after one of my views tried to use Object.assign.

[timneutkens]

I'm wondering why Object.assign would not work on older browsers since we use babel to transpile it 🤔

[bryanrsmith]

Only syntax is transpired. APIs like Object.assign must be polyfilled, and the next build doesn't include it by default. It was just an example, though. I would prefer the server rendered page remain visible on any critical error during the clients initial render.

…

On Sun, Feb 5, 2017 at 1:32 AM Tim Neutkens ***@***.***> wrote: I'm wondering why Object.assign would not work on older browsers since we use babel to transpile it 🤔 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#994 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALZUA-G9z9W09WbrimsyrY7U1A_E_m7ks5rZZdKgaJpZM4L3ZKW> .

[timneutkens]

cc @arunoda

[arunoda]

@bryanrsmith @timneutkens Object.assign issue is pretty old and related to glamor. It's being fixed.
(May be you need to use 2.0.0-beta.)

[arunoda]

If you just wanna display client side code for older browsers, we've an option.
See: https://github.com/zeit/next.js#custom-document

With this, you can identify the older browsers on the server and do not include <NextScript /> for those browsers.

[bryanrsmith]

I'm using beta 23. This issue is about script errors in general; not about a problem with Object.assign. I only used Object.assign as an example. Sorry if I didn't word it clearly.

…

On Sun, Feb 5, 2017 at 7:54 PM Arunoda Susiripala ***@***.***> wrote: @bryanrsmith <https://github.com/bryanrsmith> @timneutkens <https://github.com/timneutkens> Object.assign issue is pretty old and related to glamor. It's being fixed <#473 (comment)>. (May be you need to use 2.0.0-beta.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#994 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALZUB-_FzIQX6lik43ifXIAT_uefv2Jks5rZpl6gaJpZM4L3ZKW> .

[arunoda]

@bryanrsmith Sure.
In that case, you could try this: #994 (comment)

If that didn't work for you, go ahead and re-open this issue with more info.

[bryanrsmith]

@arunoda Thanks, but I can accomplish the desired result by tracking router events and throwing within a custom error handler to prevent it from displaying on initial render. I just opened this issue because I think the default behavior is undesirable, and it's not entirely trivial to avoid. If you think the current behavior should remain it's no problem for me :-)

[sedubois]

I do think it would be a shame to display by default an error page in the browser when the browser initially receives valid HTML but then generates an error it actually can't do anything about. The current behavior sounds more like a bug.

[arunoda]

@sedubois It's not like that.
That means, Next.js cannot run on that browser.
So, in the first place you should not allow Next.js to run on that browser.

We've ways to do that: #994 (comment)

Anyway if we got an error, we need to display it.

[sedubois]

Ok, I understand.

[bryanrsmith]

That means, Next.js cannot run on that browser.

Actually, Next.js can run just fine. It's app code in the page component that's failing.

you can identify the older browsers on the server and do not include <NextScript /> for those browsers.

Sorry, but I don't think this is a viable option. This would require tracking which JS/browser APIs are required by the application, and looking up the UA in a browser support table to check compatibility on every request... that's pretty complicated and probably unnecessary.

Anyway if we got an error, we need to display it.

I disagree. We would need to display the error if it prevented the content from being shown to the user, but in this case the user was shown the server-rendered content for a moment and then slapped with an error page. That's a bad user experience.

Here's the custom error handler I'm using to avoid this issue: https://gist.github.com/bryanrsmith/36b0faab1ec11bdf677ec982b2abce89

I totally understand if you don't want to change the default behavior of Next.js, but I wonder if anything could be done to make it easier to accomplish this. Maybe Next.js could pass a value to the error handler's getInitialProps that could be used to determine if the error happened during the initial client render (which would let me delete all the silly Router event handler code at the top). It might also be nice to document a mechanism for preventing the error view from running-- I don't know if throwing an exception there could cause future problems.

[tvararu]

So, in the first place you should not allow Next.js to run on that browser.

I agree with @bryanrsmith that this isn't a great solution.

The current approach that Next.js adopts isn't great for progressive enhancement. Users get perfectly working HTML, but if their browser encounters a runtime JavaScript error, then the rug is pulled from underneath, and the entire page is replaced with a full screen error. Users with JavaScript turned off get a better experience in this situation!

Is there an up to date workaround to disable this behaviour? The throw err inside getInitialProps hack that Bryan showed doesn't work in the latest version of Next.js.

[hyperborea]

Sad to see this ticket has been closed with no real solution. I've been running into missing polyfills a couple of times now and have found no good way to debug / error log "an unexpected error has occurred" exceptions caused by issues in client side rendering. It would be nice to at least fallback to the SSR version in these cases.

I understand as well if you don't want to change default behaviour of next, but some toggle or escape hatch would be really appreciated.

[lkbr]

Agree with @hyperborea. Also having challenges with this. We have audiences in emerging markets using browsers like opera mini and UC browser which are already challenging enough to debug.

[hansinhu]

That's a bad user experience.

[vzaidman]

maybe this is related #2468