history: Remove history.block

@cristiano-belloni I was thinking a bit more about your question, and I think this is probably the best generic solution I can come up with:

// Use this variable to keep track of the most recent location.
let prevLocation = null;

// Be sure to call this on the initial page load so that you get
// the initial POP.
history.listen((location, action) => {
  if (prevLocation) {
    if (!window.confirm('Are you sure you want to leave?')) {
      // They want to stay. Try to revert the last location change.
      if (action === 'PUSH') {
        // If it was a PUSH, goBack() should get us back to the last URL we were at.
        history.goBack();
      } else if (action === 'REPLACE') {
        // If it was a REPLACE, we can probably just do another replace with
        // the prevLocation.
        history.replace(prevLocation);
      } else { // action = POP
        // This is the hard part. We can only guess what to do here because we
        // cannot know where they came from. Should we goBack()? Should we
        // push(prevLocation) like Vue does??
      }

      return;
    }
  }

  // Save this reference for next time.
  prevLocation = location;
});

@BetterCallSky I know for a fact that both the Vue and Angular routers are heavily based on React Router (Vue’s history lib in particular is almost a direct copy of this library), so I would not be surprised if their implementations of this feature are subject to the same limitations we are. Instead of just saying “Vue and Angular can do it” and lamenting, you should actually go and build a feature of your app in either of those libraries, post it here, and I’ll show you how it has the same limitations I’ve described above.

@cristiano-belloni Yes, it shouldn’t be too hard to build out this functionality on your own. Something like this could work:

history.listen(location => {
  if (!window.confirm('Are you sure you want to leave?')) {
    // This is the hard part. You can naively say "go back", but you can't be 100% sure
    // that will take them to the location they came from. It's just a guess.
    history.goBack();
  }
});

Hi, we are happily abusing history.block in our project, . It has, in a way that reads nicely, even though it was not the original purpose, allowed us to review and control location in our state and decide that, for certain URLs, we want to perform certain actions (preloading, etc. ) before the app actually “goes there” . We’re using RxJS and this fits very nicely into a push flow. This is too short a summary, but components don’t have to cater for missing data, etc. because we have a very clean way to prevent certain URLs from being rendered until all is ready.

CC @cristiano-belloni

It’s absolutely doable. I’ve actually forked the lib and implemented it myself the right way. First of all, you need to add functionality that enables you to toggle dispatching events to the listeners on/off.

Once you’re in control of that, you can simply replace the url to the previous URL when a user tries to navigate away without notifying the listeners as if nothing has changed.

https://github.com/vuejs/vue-router/tree/dev/src/history For me, it’s a completely different implementation.

@BetterCallSky Look closer, my friend. There are numerous instances where the code in that library is copied straight from v3. One example: here’s us and here’s them … even the comments were copied from us 😅 It’s been a few years, so the code has changed over time. But when that library started it was a pretty direct copy of this one.

https://codesandbox.io/s/jzr5nojn39 Example confirm navigation in Vue. It seems to work correctly.

I made a little video to show how that example is broken:

Here are the steps to reproduce:

• Start on the home page
  • The history stack is empty
• Click through pages 1 and 2, confirming each step
  • Now you’re on page 2
  • The history stack has 2 entries in it: page 1 and the home page
• Using a click and hold on the back button, navigate back to the home page, but cancel this navigation
  • You’re still on page 2 (the navigation was blocked)
  • But the history stack only has 1 entry now!
• Click the back button
  • You should be on page 1, since that was the page you visited before page 2
  • But instead, you’re on the home page

This is because when Vue’s router cancelled the navigation from page 2 back to the home page, it could not tell where the user was coming from, so it did the naive thing and pushed page 2 back onto the stack. That’s the limitation that I was trying to describe in the OP.

@mjackson - I didn’t see the code (yet), but I was thinking - if you remove it, would it be possible to have a way to hook into history and re-implement your block “hack” on our side? That would still give history the upsides you mention, while it would mitigate the downsides on our side.

What if we would keep the allKeys array in the history API state object?

Then for a given history state, we would know:

• what were the previous browser paths before it
• or nothing (in case that this JSON data is lost i.e. on browser restart).

This would allow me to have a canGo functionality in the browsers. ( https://github.com/ReactTraining/react-router/issues/1066 ) There’s one library that kind of does it but it does it imperfectly ( I described it here https://github.com/hinok/react-router-last-location/pull/24 ).

Maybe that would also make the history.block functionality possible?

Thanks for explaining. Not sure what other people think about it, but for me, it’s a very edge case I can live with it. It’s better to lose a few history entries than the whole form 😉

So the way I’m reading it, it looks like you would need to expose the transitionManager here before people could start implementing their own replacement for block:

const history = { length: globalHistory.length, action: ‘POP’, location: initialLocation, createHref, push, replace, go, goBack, goForward, block, listen };

return history;

So… I just wanted to hop in here and say: I hate to see folks give up like this. history.block is working perfectly for us, even on iOS. But I do understand being beaten up by edge cases until one finally just gives up.

I do have a question, though.

My initial reaction is to just wire my own hook into the transition manager to replace the method you’re about to rip out… but it suddenly becomes unclear to me when you started boasting of significantly smaller code, is your intention to rip out the entire transition manager?

I did try your history.listen suggestion above in our project, but it breaks because we are using (not my choice) a yucky where we

history.push("/nullRoute"); if (history.location.pathname === "/nullRoute") { history.replace(this.props.to); }

in order to force a component refresh (it’s an IFrame component). Certainly not trying to defend this decision here, but when history.listen fires on the .push, the code calls the .back method, but then the location.pathname isn’t actually switched back before that if condition occurs on the next line, so according to the code, it looks like the user approved the switch even though they didn’t.

Without an explicit history.block method, I really do need to hook into the transition manager directly so I can set things up myself, and then things would update inline, which is what we need.

So I guess I’m hoping the plan is keep it (the transition manager)? 😃

@BetterCallSky It’s easier, safer, and less code to save the form into sessionStorage.