Allow skipping getInitialProps on history navigation

[adamwathan]

Feature request

Make it possible to somehow skip getInitialProps when a page is loaded as the result of the user navigating back/forward in history, reusing the initial props that were provided when that page was first loaded instead.

Is your feature request related to a problem? Please describe.

Demo app: Preview - Source

Right now whenever you press back or forward, getInitialProps is run which often means making a network request to fetch some data.

This is a little bit annoying when combined with same page route transitions, because it can often lead to a slower than expected user experience for something that seems like it should be instant.

For example, say you have an Instagram style page that lists a bunch of photos, and clicking one photo focuses that photo in a modal dialog, and also changes the URL.

When the user hits back (or closes the modal manually, given you've implemented closing the modal as a Router.back() call), getInitialProps runs again on the page, causing the page to wait for the network request before closing the modal.

This seems like a waste because the data that was provided on the original getInitialProps call is still visible behind the modal, fetching it again actually seems counter to what the user would expect.

This points to a bigger point of discussion which is:

Do end users generally expect history navigation to trigger a refresh of the data on the page they are navigating to?

I would argue that no, this is not really the normal behavior of the web. Hitting "back" in your browser loads the previous page from disk cache, it doesn't make a fresh network request, and I think users are actually trained to expect and rely on this behavior (ever been in a situation where your network connectivity all of a sudden went to crap and you needed to see a page you already visited and instinctively knew to navigate to it using back/forward and not by clicking any links on the page?)

There are probably a lot of Next.js apps relying on the current behavior so it's likely not something that would make sense to completely overhaul, but I think it does make sense to make it possible for users to opt-out of the "fresh props on back/forward" behavior and instead have their apps behave more like how the browser behaves by default with traditional server-rendered web pages.

Describe the solution you'd like

I'm not sure what the best API for this would look like, perhaps another option you can export in the config object for a page or something configured globally at the app level?

Describe alternatives you've considered

I tried to sort of hack this by forcing history navigation to act like a shallow link using beforePopState:

class MyApp extends App {
  componentDidMount() {
    Router.beforePopState(({ url, as, options }) => {
      options.shallow = true
      return true
    })
  }
  // ...
}

...and this actually does work for same page route transitions, but not when hitting back/forward to go from one page to another.

I also tried caching the results of getInitialProps in my page components, but it still runs the first time you hit back, since the call that happens on the server can't populate the client side cache. I'd also like to avoid worrying about cache invalidation if possible, so I'd really like to find a solution other than caching as it has implications on regular <Link>-based page navigation as well which is not ideal.

[AZIMAT]

i'm working on this, you will see the result ;)

[angelomichel]

This "Make it possible to somehow skip getInitialProps when a page is loaded as the result of the user navigating back/forward in history" is exactly what I want to prevent as well.

What is the status on this one?

ps. I am using nextjs 9 (just migrated from 8) this issue is still relevant and actually prevents a bug-free SSR-only next.js app. The solutions found online are just too messy and hacky imho so I would love feedback from the actual developers of next.js with a solution (either elegantly with current code or with a new feature somehow).

[atombender]

@AZIMAT Any update on this?

[dijs]

I am also seeing this behavior. I have zero Link components in my app, yet when using history back and forward the Router is calling getInitialProps and breaking stuff.

[dijs]

Did a bit more research here. Even though the docs clearly state you can opt-out of Automatic Static Optimization by including getInitialProps in the _app.js file, when navigation using back and forward history triggers, the getInitialProps function is still being called client side. This seems like a bug rather than a feature request.

[overide]

Any update on this? Can anyone explain how Facebook handles this on backward/forward navigation?

[stevenpetryk]

Seems like getStaticProps can be used for this now.

[adamwathan]

A relevant bit of info from the HTTP/1.1 Spec:

User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.

History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.

It's definitely surprising/unintuitive behavior that Next ever blocks on history navigation, whether using getInitialProps or getServerSideProps.

Would definitely be nice to make this configurable down the road, so that back/forward is always instant and shows the actual historical view like a regular website.

[quentinlagache]

Did last releases of Next.js have fixed this behavior or is it still an issue at the moment ? @Timer @okmttdhr

[juanmait]

For shallow back and forward you can always use window.history.back() and window.history.forward() or any other method of the browser's history API. If your app supports shallow navigation it should work our of the box.