Avoid duplicate entries

[kenchris]

This might already be covered, but I didn't find it so asking here.

In some SPA experiences you have multiple view that the users often switch between (a bit like browser tabs) - it is kind of time that hitting back brings you to the former view, but it is quite annoying that it cycles through the whole history of clicking, like

Twitter PWA: tweets, dm, tweets, dm, profile, dm, tweets.

I think a nice way to solve this would be to be able to easily avoid having duplicates and thus always remove earlier entries when readding, like the above would become:

profile, dm, tweets

I have wanted to implement such behavior in my own SPAs before

[Yay295]

This sounds like someone is using pushState when they should be using replaceState.

[kenchris]

That modifies the current history entry, which is not a solution to the above. It is about removing earlier duplicates of a new entry

[tbondwilkinson]

I think a resolution to #9 would solve this use case - namely this would be deleting entries.

As for automatic detection of duplicates and deletion, I would probably say that's too aggressive of a design decision, since there may be some pages where it's reasonable to have two "identical" states in history from the point of view of the URL.

[Yay295]

It is about removing earlier duplicates of a new entry

Using replaceState instead of pushState would mean you wouldn't find yourself in a situation where you have duplicates of previous entries.

[domenic]

This definitely makes sense, and is not at all related to pushState vs. replaceState.

I tend to agree with @tbondwilkinson that having this as a built-in "mode" is a bit fragile, and it'd be better to build on a primitive like that proposed in #9. Concretely, given something like appHistory.delete(key), you could do something like:

appHistory.addEventListener('currentchange', async () => {
  for (const entry of appHistory.entries) {
    if (isSame(entry, appHistory.current)) {
      await appHistory.delete(entry.key);
    }
  }
});

where isSame could be as simple as comparing the entries' url properties, or more complicated depending on your app's specific logic.

WDYT?

[frehner]

would it be more consistent to have delete() take in the key for an entry, like navigateTo/goTo does?

[domenic]

Yep, sorry, that's what I meant to write; I'll edit the code sample.

[kenchris]

Yes this looks good. Would be great with examples like that in explainer/spec

[domenic]

Well, we're not yet sure whether mutation of your history list should be supported, so it's currently relegated to an open issue (#9). Maybe I should add a pointer though. And I'll certainly add this as more evidence for #9 being compelling to developers.

[kenchris]

I definitely think it should be possible to modify it as long as it is from your own origin, so hope that moves forward

[domenic]

Let me roll this into #9 for now!