Using router.back() with fallback to root when no previous page

[hyjoong]

Let's assume our domain is https://shop.com

I'm implementing a custom back button and want to achieve the following behavior:

When a user clicks my custom back button (not the browser's back button):

1. If there's a previous page in the same domain, use router.back() for normal navigation
2. If there's no previous page or the previous page is from a different domain, redirect to root (https://shop.com)

Example scenarios:

• Direct access: User opens "https://shop.com/items/44" directly -> clicks back -> should go to "https://shop.com"
• Different domain: User visits "siteA.com" -> "siteB.com" -> "shop.com/items/44" -> clicks back -> should go to "https://shop.com"
• Same domain: User visits "shop.com" -> "shop.com/list" -> "shop.com/items/44" -> clicks back -> should go to previous page

Current implementation using router.back() doesn't handle these cases properly. What's the recommended way to implement this behavior?

Here's my current component:

'use client'
import { useRouter } from 'next/navigation'

export default function BackButton() {
  const router = useRouter()
  
  const handleBack = () => {
    router.back()
    // Need logic to handle no history case
    router.push('/') // root page
  }
 
  return (
    <button onClick={handleBack}>
      Back
    </button>
  )
}

[dev-kraken]

In this case, when looking to maintain the functionality of the back button, the conditions stipulated can also be fulfilled by implementing a logic that checks the presence of the entry in the history. If there is no history entry or the user has opened the page directly, we have to manage the redirection to the root page of the site (https://shop.com/).

'use client';
import { useRouter } from 'next/router';
import { useCallback } from 'react';

export default function BackButton() {
  const router = useRouter();

  const handleBack = useCallback(() => {
    // Check if there is a history entry
    if (window.history.state && window.history.state.idx > 0) {
      // Use router.back() to navigate back
      router.back();
    } else {
      // Redirect to root if no previous page
      router.push('https://shop.com');
    }
  }, [router]);

  return (
    <button onClick={handleBack}>
      Back
    </button>
  );
}

[hyjoong]

Thank you for the suggestion. However, using window.history.length has some limitations.
For example, when a user navigates from "google.com" to "shop.com/items/44", or when typing the URL directly in the browser's address bar, the history state doesn't accurately reflect our intended navigation path, making window.history.length unreliable for determining the previous page.

[dev-kraken]

You're correct that window.history.length may not be reliable in all scenarios. Instead, we can use the window.history.state object, which provides a more accurate way to determine if there is a previous page in the browser's history.

we can do something like this

  const handleBack = useCallback(() => {
    // Check if there is a history entry
    if (window.history.state && window.history.state.idx > 0) {
      // Use router.back() to navigate back
      router.back();
    } else {
      // Redirect to root if no previous page
      router.push('https://shop.com');
    }
  }, [router]);

The window.history.state object contains information about the current history entry. The idx property indicates the index of the current history entry in relation to the session history. If idx is greater than 0, it means there is a previous entry in the history stack.

[hyjoong]

I've tested this approach with window.history.state.idx in my application where I primarily use Next.js's Link component for navigation. When testing the following navigation flow:

"shop.com" -> "shop.com/list" -> "shop.com/items/44"

Clicking the back button triggers the handleBack function, but it unexpectedly hits the else condition and redirects to the root page instead of going back to "shop.com/list".

[icyJoseph]

I think the idea of using idx has been implemented by some, #37192 (comment), but like, yeah it is not ideal, and in that linked PR, the idx was about to be changed to a key, rather than numeric ever incrementing id. It is kind of brittle to rely on an internal, that's not part of a public API.

Maybe... you could replaceState on landing, and extend the state of that entry with a marker of your own? maybe even mutate the state of the first entry as you land, with such marker. That way you don't depend on Next.js' idx, though, you do depend on state being an object... and state can be anything really... I remember an issue where a 3rd party was pushing an '', to the history 😅

• Error thrown when window.history.pushState is called with "" as the first argument #68015

Yet another reason to not rely on idx I guess. They did suggest tracking this yourself, on an in-memory stack, or in session storage perhaps?

[hyjoong]

Thank you for the detailed explanation! Yes, you're right about the risks of relying on internal implementations. After reading about these edge cases and potential issues with window.history.state, I'm starting to think that handling proper back navigation is more complex than it initially seemed. Looks like there's no simple solution for this 😢