Cancel Rendering Route Error when Router Push hash

[michalbundyra]

Verify canary release

• I verified that the issue exists in Next.js canary release

Provide environment information

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.15.0
      npm: 8.5.5
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 12.1.7-canary.26
      react: 18.1.0
      react-dom: 18.1.0

What browser are you using? (if relevant)

Google Chrome Version 102.0.5005.61 (Official Build) (arm64)

How are you deploying your application? (if relevant)

Locally and Vercel

Describe the Bug

Similar to #36830 (fixed by #36828)

trying to store more information in hash, getting "Cancel rendering route" error when pushing updated hash to router:

Expected Behavior

Pages changes without error.

To Reproduce

git clone https://github.com/michalbundyra/hash-cancel-rendering-route
cd hash-cancel-rendering-route
yarn
yarn dev

1. Go to http://localhost:3000/
2. Click "to world"
3. Error pops!

[icyJoseph]

This is really strange. Surprised that the #36828 fix didn't work for this case.

For what is worth, I think it is best to treat push as what it is, async work and do this instead:

router
     .push("/blog")
     .then(() => router.push("#hello"))
     .then(() => router.push("#hello-world"));

This also used to break before #36828 but now it is safe to do.

[michalbundyra]

@icyJoseph thanks for your response. I think the problem is more complex, and I am not sure if I can use await/then. I have simplified to the very basic case based on the previous issue.

In my case I want to store in the hash tab-id and filters for a specific tab. There might be default filters for a tab, but these are set on the component, so the tab change is though Link and then route.push just update the hash again to set default filters. So honestly with this approach I cannot await and I hoped it could be fixed in the framework itself, as the very similar issue was.

Please let me know what you think. Thanks a lot!

[icyJoseph]

I figured the reproduction demo was oversimplified, but it was worth a try 😅

Yeah, I mean this should somehow be fixed here, I might try to take a stab at it again, I saw that a maintainer added a test for my fix, so I can try a bit more stuff there.

So you first navigate to a tab, then each tab has a set of properties that are pushed to the url as part of the hash

#tab2-sortasc-radios-brand

Something like that, but first you move onto the #tab2 state, and then when the component for that tab mounts, it updates to the final hash, right?

Ah this could be done in other way, but it'll be unmaintainable I think (using refs and what not).

Never mind that perhaps this has to be fixed, and that sequential calls to async work do not necessarily resolve in order, have you considered using queries for the filters?

Normally queries are key, value pairs, but they don't have to be so, and in the case you describe, it sounds like they are. I would hope that the same error doesn't happen, if one updates the queries on the page, with shallow set to true.

[michalbundyra]

@icyJoseph thank you very much for your time and response.

Something like that, but first you move onto the #tab2 state, and then when the component for that tab mounts, it updates to the final hash, right?

Correct.

have you considered using queries for the filters?

Yeah, I have considered using query params for the filters, but it was also quite complex, as still I have tabs and can have different set of the filters on different tab. So I would need to clean query parameters when jumping between tabs. For me preferably would be to use just path + query filters, but we have tabs - and the current tab is using hash. Changing query params refreshes parent component so clean the state of current... probably I could do something here... probably.

I started investigating another approach - to set the default filter on tabs directly, and it also solves the issue: so my link to the tab is #tab-with-filters instead of #tab so there is no extra router push on binding the tab component.

Probably this is going to be the best solution for me and it would work with current stable release as well.
I just would need to move my default filters from the tab component one level up, that's why I didn't like it too much.

Anyway. it's not very urgent for me, so I can wait and see if there will be any fix here. If it would be "won't fix" I can probably implement the solution I've described above.

Thanks again for your help and time 👍

[domasrc]

Having the same error just by clicking quickly on nav links with hashtag hrefs. Seems that the error is triggered when the hash link is clicked before it fully scrolled up/down to the hash clicked before.

React 18.1 / Next 12.1.6

[bline]

Has there been any progress on this or workarounds? I'm running into this trying to manage anchor links and a back-to-top button. My scrollToTop handler looks line this:

  const scrollToTop = useCallback(async () => {
    if (!router.isReady) {
      return;
    }
    const rootPath = router.asPath.replace(/#.*/, '');
    router.push(rootPath, rootPath, { scroll: false, shallow: true }).catch((e) => {
      console.log("router.push error", e);
    }).finally(() => window.scrollTo({ top: topOfPage, behavior: 'auto' }));
  }, [topOfPage, router.isReady]);

Not sure if the router.isReady stuff is needed there but added it to try and solve the issue, it didn't.
Even with the catch() in there, I still get the Error: Cancel rendering route thrown if the user clicks the back to top button before the images in that section fully load.

react@18.2.0
next@12.2.0

[AlexandraKlein]

I'm getting this error with the following code:

       router.push(
            {
                pathname: '/',
                hash: 'hash',
            },
            undefined,
            { shallow: true }
        );

The hash bit seems to be the offender. Removing it removes the error.

If I switch from hash to query params, there is no error:

      router.push(
            {
                pathname: '/',
                query: { section: "section" },
            },
            undefined,
            { shallow: true }
       );

Versions:
"react": "18.2.0",
"next": "12.2.5",

[laclance]

any updates? do we have to use query params over hashes to get rid of the error?

[theresaluu]

I'm going to use the following until there is a fix

import { useRouter } from 'next/router';

const router = useRouter();
const pathAndSlug= router.asPath.split('#')[0];
const newPath = `${pathAndSlug}#${hash}`;
  
window.location.replace(newPath);

[bordeo]

I'm using this workaround

router
  .replace( // or push or whatever you want
    {
      pathname: window.location.pathname,
      hash: newHash,
      query: window.location.search,
    },
    null,
    {
      shallow: true,
    }
  )
  .catch((e) => {
    // workaround for https://github.com/vercel/next.js/issues/37362
    if (!e.cancelled) {
      throw e
    }
  })

[MAfzalKhan1997]

any solution to this yet ? It comes after I upgraded react to 18 either with next version 12 or 13 error is appearing... there is no hash routing in my app and it is only happening for dynamic routes.

[yhafez]

Also wondering if there's a solution to this yet.

A standard accessibility practice is to have a link to the main tag of a page at the very top of a page's body so that screen reader users can use it to skip over hearing the navigation sections at the beginning of a page over-and-over again. I'm having trouble doing that because of this issue.

I've given my main tag an id of "main" and am attempting to use the router to push the current page to it, and am getting the same error.

[Historia2]

Any updates for this?

[Webbrother]

Hello from future.
Still no updates on this?