This repository was archived by the owner on Aug 21, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 21, 2026. It is now read-only.
Should event.destination contain useful id/key/index for non-"traverse" navigations? #138
Description
Spinning off from #97, re-summarizing based on the current state of things.
Currently event.destination in the navigate event contains:
url,sameDocument, andgetState(), alwayskeyandid, which are the relevant value for"traverse"navigations but null for"push"/"replace"/"reload"navigationsindex, which is the relevant value for"traverse"navigations but -1 for"push"/"replace"/"reload"navigations
Should we change either of these last two bullets? Some ideas:
indexis always easy: it's eithernavigation.currentEntry.indexfor replace/reload, ornavigation.currentEntry.index + 1for push.keyis easy for replace/reload: it's alwaysnavigation.currentEntry.key.- Beyond that,
keyandidare a bit trickier to implement and spec as we'd essentially have to generate them up front and thread them through, instead of generating them once the navigation finishes and we update the entries list. It's still probably doable though, if there's a use case.
I'm reasonably happy with having these be null/-1 for now, but I'd like to have this issue to track if people have any use cases for key/id/index on non-"traverse" navigations.
Activity
domenic commentedon Mar 17, 2022
@annevk, @smaug----, @natechapin and I met offline and were unable to think of any compelling use cases for this. In addition @natechapin confirmed that the plumbing work would be quite a lift to implement, at least in Chromium.
We'll consider this settled in favor of the status quo. (Which is tested a good amount in web platform tests already.)
This isn't impossible to change after initial implementations, so if someone discovers a really key use case please let us know. (Any compat issues would come about if people start using these null/-1 values as signifiers of non-traverse navigations, instead of using
navigationType !== "traverse". Which seems like something people would do, eventually, but probably wouldn't do in the early days of this API's existence.)