18

When I navigate to a new page, Reach Router scrolls down to the page content past the header (if the content is long enough). I'm assuming this is for accessibility but it's not necessary for my app and it's actually quite jarring. Can this behaviour be disabled?

Note that I'm talking about Reach Router not React Router.

Reach Router

c-chavez
  • 5,673
  • 4
  • 28
  • 43
Evanss
  • 17,152
  • 66
  • 217
  • 397
  • I had the same problem and I tweeted about it to the maintainers. Here's the response: https://twitter.com/ryanflorence/status/1057280035810410496 – Daksh Miglani Oct 30 '18 at 14:37
  • Same problem here. Is there a way how to execute some code after each route navigation (or each call to `navigate()`)? I would simply put somwthing like `window.scrollTo(0, 0)` there. – Rasto Apr 11 '19 at 05:16
  • Can you create a small demo for your problem – Shubham Khatri Apr 12 '19 at 08:26

7 Answers7

14

Try using <Router primary={false}> which will not focus on the route component.

https://reach.tech/router/api/Router

primary: bool

Defaults to true. Primary Routers will manage focus on location transitions. If false, focus will not be managed. This is useful for Routers rendered as asides, headers, breadcrumbs etc. but not the main content.

WARNING: If you are concerned about breaking accessibility please see this answer: https://stackoverflow.com/a/56996986/428780

Vinicius
  • 766
  • 10
  • 18
  • 3
    Does not help, still scrolls to some strange offset – Rasto Apr 11 '19 at 04:56
  • 1
    Create a codesandbox with your code so we can see it – Vinicius Apr 26 '19 at 21:59
  • Warning - I would **not** recommend this approach. It breaks accessibility, which is one of the main reasons for using Reach Router in the first place. [See my answer](https://stackoverflow.com/a/56996986/1082449) for more info. – davnicwil Jul 11 '19 at 20:41
  • @davnicwil I understand you're concerned about other people using this solution but as the OP stated: "I'm assuming this is for accessibility but it's not necessary for my app", so this IS the right solution for him. – Vinicius Jul 12 '19 at 00:54
  • @Vinicius Yeah, that's fair. And not trying to say you've not solved the OP's problem. I just wanted to flag up that this probably isn't the best general solution here for most people using Reach router, for anyone that comes here and just picks the answer with vastly more votes than the others on trust, perhaps missing that detail because they're busy / in a rush. – davnicwil Jul 12 '19 at 08:10
10

The top answer here, while solving the OP's problem, is probably not the solution most people want, since it turns off the most important accessibility feature of Reach router.

The fact Reach router focuses the content of the matched <Route> on a route change is for accessibility reasons - so screen readers etc can be directed to the newly updated, relevant content, when you navigate to a new page.

It uses HTMLElement.focus() to do this - see the MDN docs here.

The problem is that by default, this function scrolls to the element being focused. There is a preventScroll argument which can be used to turn this behaviour off, but the browser support for it is not good, and regardless, Reach Router does not use it.

Setting primary={false} turns this behaviour off for any nested <Router> you may have - it is not intended to set false on your main (primary) <Router> -- hence the name.

So, setting primary={false} on your primary <Router>, as the top answer suggests, 'works' in the sense that it stops the scrolling behaviour, but it achieves this by simply turning off the focusing behaviour completely, which breaks the accessibility feature. As I said, if you do this, you're breaking one of the main reasons to use Reach Router in the first place.

So, what's the solution?

Basically, it seems that this side effect of HTMLElement.focus() - scrolling to the focused element - is unavoidable. So if you want the accessibility feature, you have to take the scrolling behaviour with it.

But with that said, there might be a workaround. If you manually scroll to the top of the page using window.scrollTo(0, 0) on every route change, I believe that will not 'break' the focusing feature from an accessibility perspective, but will 'fix' the scrolling behaviour from a UX perspective.

Of course, it's a bit of a hacky and imperative workaround, but I think it's the best (maybe only) solution to this issue without breaking accessibility.

Here's how I implemented it

class OnRouteChangeWorker extends React.Component {
  componentDidUpdate(prevProps) {
    if (this.props.location.pathname !== prevProps.location.pathname) {
      this.props.action()
    }
  }

  render() {
    return null
  }
}

const OnRouteChange = ({ action }) => (
  {/* 
      Location is an import from @reach/router, 
      provides current location from context 
  */}
  <Location>
    {({ location }) => <OnRouteChangeWorker location={location} action={action} />}
  </Location>
)

const Routes = () => (
  <>
    <Router>
      <LayoutWithHeaderBar path="/">
        <Home path="/" />
        <Foo path="/foo" />
        <Bar path="/bar" />
      </LayoutWithHeaderBar>
    </Router>

    {/* 
        must come *after* <Router> else Reach router will call focus() 
        on the matched route after action is called, undoing the behaviour!
    */}
    <OnRouteChange action={() => { window.scrollTo(0, 0) } />
  </>
)
davnicwil
  • 20,057
  • 9
  • 87
  • 98
4

Building off of @Marcus answer, you can get rid of the jank with useLayoutEffect() instead of useEffect() - this way the scroll action happens after the DOM has been fully rendered, so you don't get the weird "bounce."

// ScrollToTop.js
import React from 'react'

export const ScrollToTop = ({ children, location }) => {
  React.useLayoutEffect(() => window.scrollTo(0, 0), [location.pathname])
  return children
}
  • Perfect, with scroll behaviour set to smooth it even has a nice animation. Other answers did not solve the issue for me, even `primary={false}`, in a react-static app. – Eric Burel Sep 02 '19 at 14:06
  • I'd like to add that if you're using Code Splitting and `React.Suspense`, you need to add the hook without the location `useLayoutEffect(() => window.scrollTo(0,0))` to the fallback component you're using. Otherwise, it won't scroll to the top. – Jose A Jul 21 '20 at 16:48
3

I had to use a combination of things to make it work. Even with setting primary={false} there were still cases where the pages would not scroll to the top.

      <Router primary={false}>
        <ScrollToTop path="/">
          <Home path="/" />
          <Contact path="contact-us" />
          <ThankYou path="thank-you" />
          <WhoWeAre path="who-we-are" />
        </ScrollToTop>
      </Router>

This is based off of React Router's scroll restoration guide.

The scroll to top component will still work with you don't have primary={false}, but it causes jank from where it focuses the route and then calls window.scrollTo.

// ScrollToTop.js
import React from 'react'

export const ScrollToTop = ({ children, location }) => {
  React.useEffect(() => window.scrollTo(0, 0), [location.pathname])
  return children
}

Marcus Wood
  • 116
  • 5
0

There must be another thing to cause this. Like @Vinicius said. Because for my application primary={false} really works. I have a small application and my routes below.

<Router primary={false}>
  <Home path="/" />
  <Dashboard path="dashboard" />
  <Users path="users" />
  <Sales path="sales" />
  <Settings path="settings" />
</Router>
Erdal SATIK
  • 573
  • 1
  • 6
  • 25
  • How do you actually trigger navigation? Using `Link` or using `navigate` or some orher way (e.g. `Redirect`)? Does it work with all those methods? – Rasto Apr 11 '19 at 17:13
  • 1
    Also, do you actually have at least 2 pages long enought so that they can be scrolled down? Without that the issue is not noticeable. – Rasto Apr 11 '19 at 17:14
  • I am using "Link" from @reach/router. And yes Sales, Users pages are really long pages, there is no pagination. But it doesn't scroll to the content.Stays top. – Erdal SATIK Apr 11 '19 at 19:13
0

Using primary={false} does not solve all the cases. A common solution is to wrap the page and use useEffect to achieve the result. There might be a flash issue as someone pointed out, although it never happened to me, so try your luck.

<PageWrapper Component={About} path="/about" />

const PageWrapper = ({ path, Component }) => {
  useEffect(() => {
    window.scrollTo(0, 0)
  }, [path])

  return <Component path={path} />
}

As a notice, in React Router, you could use history.listen as explained here. I did not check if there is a similar solution in Reach Router, but that solution would be more optimal.

lehoang
  • 1,937
  • 1
  • 9
  • 15
0

I made an npm package out of it to make integration simple: https://www.npmjs.com/package/reach-router-scroll-top

Dark Smile
  • 65
  • 4