next@beta-31 breaks navigation on page

[khrome83]

When loading page, the follow displays within the error console. This was after switching to next/link over the older next/prefetch

Upon clicking a link, the following error is generated in the console.

Upon generating these errors, navigation does not continue to the next page, and instead shows the current page and destroys all existing styles.

Example Code -

import React, { PropTypes } from 'react';
import Link from 'next/link';
import SVG from './SVG';

function Logo({ href, title, id, width, height }) {
  const linkProps = { title };

  return (
    <span className="logo">
      <Link prefetch href={href} >
        <a {...linkProps} >
          <SVG id={id} width={width} height={height} />
        </a>
      </Link>
      <style jsx>{`
        .logo {
          color: #F0F;
        }
      `}</style>
    </span>
  );
}

Logo.defaultProps = {
  width: 'auto',
  height: 'auto',
};

Logo.propTypes = {
  href: PropTypes.string.isRequired,
  title: PropTypes.string.isRequired,
  id: PropTypes.string.isRequired,
  width: PropTypes.string,
  height: PropTypes.string,
};

export default Logo;

[khrome83]

When removing prefetch from link declaration, I still get a 404 error for prefetching. This means that any link will cause the prefetch issue.

Clicking on a link causes the same issue, producing the second set of errors.

[khrome83]

I can confirm that in Chrome, the with-prefetch example generates the 404 error as well. But you can navigate between pages. Researching to see if this is because of using a custom layout or a _document.js file.

[khrome83]

Removing _document.js and _error.js did not change the outcome.

Clicking on Link #1 created the screen shot below.

Clicking on Link #2 would produce the console errors. But it would render the same exact same page as / without styles. Clicking Link #2 again would navigate me to the correct page.

Clicking Link #1 from the "correct" Link #2 page would navigate me correctly to Link #1.

Update - This seems to be a caching issue that they are not behaving the same. Refreshing the cache seemed to remove the "purple" error screen.

[khrome83]

Link #1 Page is -

import Layout from '../layouts/Legal';
import P from '../components/P';

export default () => (
  <Layout title="Privacy Policy">
    <P>Privacy Policy content coming soon</P>
  </Layout>
);

Link #2 page is

import Layout from '../layouts/Legal';
import P from '../components/P';

export default () => (
  <Layout title="Terms and Conditions">
    <P>Terms and Conditions content coming soon</P>
  </Layout>
);

They share the same navigation that makes references to them. It is consistent though that the behavior affects them differently, yet the pages render the same.

Additionally, navigation to http://localhost:3000/terms or http://localhost:3000/privacy works just fine and I can navigate directly with zero issues. This is a problem with the Link functionality.

[khrome83]

Errors are still generated in the console when using npm build and npm start.

But you are able to navigate between pages. The lack of the ability to navigate seems to come from npm run dev only.

Building does not remove the following though. Still see this without the prefetch attribute set on the Link.

[khrome83]

Re-enabling prefetch and testing with npm build and npm start does work to handle the prefetch (still breaks Jest), but still causes the same console errors.

Here is the view from the network panel.

[nkzawa]

@khrome83 We recently removed Service Worker but it remains on your Browser which might cause these errors. Can you remove it on chrome://serviceworker-internals and see what happens ?

[khrome83]

@nkzawa makes sense. I did not realize that they did not get removed.

Out of curiosity, is there a way to tell chrome to remove the service worker without having a user go to the chrome://serviceworker-internals location and manually doing it?

Seems like maybe it would be a good idea to unregister the service worker if the service worker was used in next@master.

See MDN

[nkzawa]

Yeah, actually the unregisteration was added once but removed. 1b9e877

I don't know why though 🤔 @rauchg

[timneutkens]

@nkzawa probably because it removes all services workers instead of just ours 😰
Also, this was released in beta.29 and remove in beta.32. So it might be just the comment 'Remove in future release'.