Updating, deleting, and rearranging non-current entries

[domenic]

Because the navigation API is scoped to same-origin same-frame history entries, we have a lot more freedom to allow manipulating it, compared to the joint session history represented by window.history. In particular, we could allow rearranging or removing history entries, or even updating their URLs. This is not a security issue, because it only changes the behavior of the app with respect to itself: e.g., if you delete the previous app history entry, that's basically the same as doing window.onload = () => history.back() on the previous page (which, again, is part of your origin).

There's a few cases people have cited where this might be useful:

• Invalidating logically-deleted history entries, either by deleting them or maybe by changing them to point to a 404 page or something: https://mobile.twitter.com/juandopazo/status/1356689596805836802 /cc @juandopazo

• Implementing stack-like navigation patterns: https://mobile.twitter.com/buildsghost/status/1356661396717543424 and https://mobile.twitter.com/maxlynch/status/1356672792226394113 /cc @mlynch. This would require some bookkeeping by the application or framework, and wouldn't be provided out of the box, but I believe the main primitive necessary is rearranging existing entries.

... probably there are more? Let's use this issue to track discussion.

Updating non-current entries' URLs and states, as opposed to deleting/rearranging them, is related to #7, but I think the lower-level concerns there are somewhat orthogonal to this thread. That is, whatever conclusion #7 comes to for updating the current URL and state, will probably port over to non-current entries, if we decide that such modifications would be useful.

[juandopazo]

Hi! Very happy to see this!

There's few unique use-cases we've had to deal with in terms of navigation that lead us to build our own routing instead of relying on something like react-router. We found that we needed access to the whole history stack and we would've benefited from being able to rewrite it entirely.

Deleting items

A very common UI pattern is to have a list of items (emails, recipes, news articles) and be able to open those items into a view. This should naturally navigate. Deleting or invalidating these items will usually also cause a navigation. In most cases this navigates back to the list. To add headaches to our specific case, this is configurable and it can either go back to the list or forward to the next item in the list. This forces our navigation to have to always be "forward".

The issue is that if the user clicks the back button after performing the deletion, in the current state of affairs this will navigate to the previous item in the stack, which now points to something that doesn't exist. We're then forced to chose between either showing an error page -not a great UX- or ignoring the URL and looking back in time to the previous valid state.

With this approach of going back to the last valid state, if our history was [LIST] -> [ITEM] -> delete -> [LIST], clicking back will do nothing as it will just land in [LIST] again. This is not a great UX either.

What made it extra hard

Because of these issues with the lack of control over the browser history we had to treat every in-page navigation (even the ones that say "go back") as adding new browser history entries. This lead to answering the question "what does the in-page back button do?" to be hard to answer. In practice we had to keep our own history stack with a both an idea of an active index (similar to the browser's) and a pointer to where "back" is for each entry in the stack.

This worked, but it was tough. I don't believe users expect this behavior in a web app. Much less in a PWA without a browser chrome. It would be much better to just be able to navigate back in the browser's history. Then PWA navigation would feel very much like a native app (the in-app back buttons would do the same as the native back button). I'd like to see this as the goal of a new browser API.

Dialogs

Another similar case where manipulating the history would be beneficial to web apps is dialogs, particularly in Android. Android users are able to dismiss dialogs with the back button. Since we don't have options to customize dialogs, we end up creating them in HTML. But assigning them full history entries with their URL is not great as dismissing the dialog and clicking back would take the user back to the dialog. This is a case covered by stack navigation patterns if I'm not mistaken.

[domenic]

This is great feedback, thanks! I really appreciate the extra detail on the deleting items case.

So, let's say we added a appHistory.deleteEntry(key) function. Would that then allow you to give the ideal UX? Would it allow the in-page back button to use appHistory.back()? I'd be interested in hearing more about how it would change your codebase and UX.

On the subject of dialogs and the Android back button: our belief is that this is best handled via a dedicated separate proposal: WICG/proposals#18 . Having to abuse the history API (either old or new) to implement the back-button-on-mobile-equals-Esc-on-desktop pattern is not great, and so by working on a separate API for that, we can avoid the complications there infecting the app history API.

[juandopazo]

Re: dialogs, makes sense! Let me take a look.

If I had a full CRUD set of methods for the app's history, I'd probably never write a history stack in JavaScript state again. I'd probably go back to treating the browser's history state as the source of truth. I believe this would likely be the position of open source framework authors as well. We should try to get them to chime in.

There would be some edge cases not covered. It's likely our UI would still be a function (appHistory, appState) => UI, but the cases where there is an inconsistency with the app state are going to be few and I'd treat them differently.

For example, right now when the user refreshes the browser in a certain route we give up recreating the history. If we could treat the app history as the source of truth, we could traverse it to build our UI. If we have a "stack of cards" navigation UI (the typical mobile app UI), when the user refreshes we could rebuild the stack of cards with empty states. Right now we give up and go back to the base URL.

[tbondwilkinson]

I think deleteEntry is very reasonable.

Trickier is deciding how to enable full modification of the stack.

I might suggest enabling some method to stash a full stack and/or replace it with another (or an existing)? But that's pretty radical. Domenic do you have any API suggestions of what that might look like?

[domenic]

I discussed this issue with some implementation folks this morning and the biggest takeaway was that we'd need to propose a more full model for what happens to iframes (including cross-origin iframes) in such modification scenarios. And, also how it'd impact the user's back button perception.

@jakearchibald is creating a collection of weird scenarios with iframes; once we have those then we can try to define what a deleteEntry() would do in each case, or what a stash-and-replace would do.

[Yay295]

If there's a way to delete entries there should probably also be a way to insert entries.

[tbondwilkinson]

I'm not convinced there needs to be a way to insert entries. Can you expound on what use case that would enable?

I think the ability to insert entries is just quite abusable.

[domenic]

Adding a quick note about the connection with the proposed history.clear() API: whatwg/html#5744 .