[v6] Adding useHistory hook

[asterikx]

I think the history object should be exposed in some way (also for backward-compatibility reasons).

My use case requires to listen to navigation changes before they happen (I have toast messages on my page that I need to dismiss before navigating to another route. Dismissing them after navigating to another route does not work as I might be dismissing toast messages on the page that I'm navigating to as well.)

history.listen seems to fit my use case (see here), but unfortunately, history cannot be accessed in v6.

[mwmcode]

Also #5210

[sebascomeau]

I also need a way to display a Progress bar before the history change then in the final route element calling my progress context to stop the progress when the loading is done. Right now I have a useEffect on my ProgressContext and ViewComponent. The context useEffect is triggerd when it's mounted and also when the location's pathname changed. The useEffect in the view component call stop when the data fetch is done. The useEffect of the view is called before the context then my progress bar is never stopped. Adding a listener on the history could fix my issue by thriggering the context useEffect before the action location change then the view stopping it. Maybe I'm implementing this wrong.

[sebascomeau]

I found a solution to my probleme by creating a component that return <></> and put this component early in the app tree. Im using useLayoutEffect with my context function to start the progress when pathname change.

import React, { useLayoutEffect } from 'react';
import { useLocation } from 'react-router-dom';
import { useProgress } from './contexts';

const AppEffects = () => {
  const { pathname } = useLocation();
  const { startProgress } = useProgress();

  /**
   * Starts the page progress bar whenever the router path changes.
   */
  useLayoutEffect(startProgress, [startProgress, pathname]);

  return <></>;
};

export default AppEffects;

I need to call context stopProgress in the view compoents when the loading is done.

[malj]

I also needed history.listen so I ended up reimplementing v6 BrowserRouter:

import { createContext, useContext, useRef, useState, useLayoutEffect } from "react"
import { createBrowserHistory } from "history"
import { Router } from "react-router-dom"

const HistoryContext = createContext()

export const useHistory = () => useContext(HistoryContext)

export default function BrowserRouter({ children }) {
    const { current: history } = useRef(createBrowserHistory({ window }))
    const [{ action, location }, setHistoryState] = useState({
        action: history.action,
        location: history.location,
    })

    useLayoutEffect(() => history.listen(setHistoryState), [history])

    return (
        <Router action={action} location={location} navigator={history}>
            <HistoryContext.Provider value={history}>
                {children}
            </HistoryContext.Provider>
        </Router>
    )
}

My use case is a navigation overlay which needs to close each time user clicks a link. Using @sebascomeau's solution with useEffect and location.pathname isn't ideal, because the overlay should close even when clicking on the current page link (i.e. when pathname stays the same, but history changes).

Alternatively, you could consider exposing just the history change event via a hook, e.g. useHistoryListener:

import { useHistoryListener } from "react-router-dom"

useHistoryListener(state => {
    // the same callback you'd pass to `history.listen`
})

[GeoMarkou]

Some things feel impossible in v6 moving from v5

1. We have a form on the page. If the user presses Back on their browser they will lose all their hard work so we display a Prompt. With usePrompt() and Prompt there is no longer an option to pass in a function for the 'message' parameter to customise whether to block at all depending on the URL or other state.

Before:

// Generic component used on every page with a form, it was even possible to display a custom UI for a better-looking prompt by storing location
<Prompt when={ true } message={location => {
    if (location.state?.noprompt) {
        return;
    }

    return NavigationBlockMessage;
}}>

const SubmitForm = async () => {
    await $.ajax({
        ...
    });

    // Simply pass in noprompt to the location.state when we don't need a dialog
    history.push('/complete', { noprompt: true });
}

v6:

const [ SubmitFormWorkaround, SetSubmitFormWorkaround ] = React.useState(true);
usePrompt(NavigationBlockMessage, SubmitFormWorkaround);

const SubmitForm = async () => {
    await $.ajax({
        ...
    });

    // Now we have to do a complex UseState workaround to not display a popup prompt...
    // This will also break if the user clicks other links while loading since the prompt has been disabled in general
    SetSubmitFormWorkaround(false);
}

React.useEffect(() => {
    if (!SubmitFormWorkaround) {
        navigate('/complete');
    }
}, [SubmitFormWorkaround]);

[rkingon]

I too am encountering this issue while trying to use React Albus (https://github.com/americanexpress/react-albus).

Maybe, a solid option would be to have the app create the browser history instance, then pass it to <BrowserRouter> as a prop? this way other areas of the app can use it without being coupled to React Router?

[amal-shaji]

I'm seeing this issue as well on top of an extremely wierd related issue with useLocation hook.

Any useEffect with location.pathname or any other property of location as a dependency will get rerun even when the location and location.pathname had never changed(actually location changes without route change) .

#7059 (comment)

I'm also working on overlays similar to @malj and I migrated from a perfectly functioning history.location as the useEffect dependency for the same code.

v6 unfortunately seems like two steps forward and three backwards because of this and the lack of history access.

@sebascomeau seems to be using location.pathname as a dependency. Does this work for you on 6.0.0-beta-0

[aubreyzulu]

use this simple solution `

const App = ()=>{
const { pathname } = useLocation();

  useEffect(() => {
// when ever the location(pathname) changes do some stuffs in here 
    console.log(pathname);
  }, [pathname]);
} 

`

[ssh-peppe]

I second this. Another problem is that the navigation action (push, pop, replace) is not exposed. This means that if you have code that relies on it then migrating to v6 becomes hard or impossible. E.g. you might have code that always loads fresh data on a forward navigation, but restores the data from an internal cache and restores the scroll position on back navigation. Which one you should use is impossible to know without access to the navigation access. Whether it's the history as such, or functionality that's lost by not exposing it, is another matter.

[kraegpoeth]

I would love to be able to navigate to another route from inside my store (zustand js). window.location.href, is a hard refresh, so definately a no go. I cannot even pass a custom history into react-router's anymore as was possible in v5.

Only allowing navigation from hooks is too limited imo.

Other than that i really like the v6 - keep up the good work! 💪

[mjackson]

My use case requires to listen to navigation changes before they happen

@asterikx If you really need to run some code before the URL changes, your best bet is to run it in your <Link onClick> handler. When the history.listen callback fires, the URL has already changed. So if you're setting up your own history.listen callback with the instance you get from useHistory, you're not going to be notified of the location change until after your <BrowserRouter> has already set state with the new location. But this won't even work for location changes that are initiated manually with the back button or by pasting a URL directly into the address bar.

What I think you mean by "listen to navigation changes before they happen" is you want to run some code before we set state with the new location. We don't currently have a hook for this, but maybe we could. We could probably even give you prevLocation and nextLocation.

function App() {
  useBeforeLocationChange((prevLocation, nextLocation) => {
    // run some sync code...
  });
}

Would that work for you?