History entries as a list or a tree

[Yay295]

Currently history entries act as a list. As you push more entries the list gets longer, and if you go back to a previous entry and make another push it overwrites all of the previous future entries. I think this makes sense, and it's how a lot of other things work on computers as well (ex. undo/redo when typing a document). However with this new API each entry has a unique key, and as @domenic mentions in #7, this could lead to problems if you try to navigate to an entry that has been overwritten:

const uniqueKey = appHistory.currentEntry.key;
appHistory.replaceCurrentEntry();
appHistory.navigateTo(uniqueKey);

However, if history entries were treated as a tree rather than a list, the above code would not cause issues. There is even some allowance for this in the existing History API: https://html.spec.whatwg.org/multipage/history.html#history-notes

The History interface is not meant to place restrictions on how implementations represent the session history to the user.

For example, session history could be implemented in a tree-like manner, with each page having multiple "forward" pages. This specification doesn't define how the linear list of pages in the history object are derived from the actual session history as seen from the user's perspective.

With the existing History API there is no way to actually navigate a tree, but with this new API there is.

[tbondwilkinson]

I think there's some overlap between this and #9 - would you agree?

[Yay295]

There is some, but I think treating application history as a list or a tree is mostly orthogonal to the API for navigating that list/tree. The only difference I could see is that if it were treated as a tree if would be useful to have a way to get a list of the "children" of an entry. Every other action would work fine either way as long as you keep track of a main branch for the tree.

[domenic]

I don't think this issue should impact our API design. Fundamentally, all browsers present history as a list to the user, and need to maintain an internal data structure which corresponds to that.

The throwaway note in the HTML spec about presenting as a tree is mainly to emphasize that the HTML spec doesn't constrain browser UI; it only constrains the underlying data model. That said, the fact that the app history API preserves and exposes information about all the entries does mean that applications could present a tree view of the history to their users, in the same way the HTML spec talks about browsers hypothetically being able to do. I'd be curious to see some example code in that regard, if you have ideas.

Regarding retrieving data from replaced entries, let me open a new issue about that. But I think the solution there isn't related to trees so much.

[Yay295]

One example I can think of would be having a page like /edit that has a list of things to edit. Then you could go to /edit/a to edit one thing, and the page would save the in-progress edit to the history state. Then going back (without committing the edits) wouldn't lose your edits. Currently however if you went back to /edit and forward to /edit/b you would lose the history for /edit/a. If you could have multiple "forward" states the history for /edit/a wouldn't be lost. Knowing which forward states exist would allow the /edit page to mark current edits as in-progress.

[domenic]

Sure. But that's not compatible with browser's existing history models of a single linear joint session history (which we're not proposing to change), so it'd be something for the application to track by storing the appropriate data from appHistory.entries[appHistory.current.index + 1].

[Yay295]

It could be compatible if you keep track of which child entry is the most recent and ignore the other entries when using the existing interfaces.

[domenic]

I'm talking about compatibility with the model, not the API.