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.
event.destination should not be an AppHistoryEntry. How should it behave? #97
Description
As I started trying to spec event.destination, I realized making it an AppHistoryEntry would not work very well. In particular, only sometimes would we be able to get the right object identity, i.e. the one that matches up with appHistory.entries() or appHistory.current after the navigation. And, adding event listeners doesn't make much sense. And, the semantics of index were strange.
So we should definitely divorce event.destination from the AppHistoryEntry instances that live in appHistory.entries(), and instead make it a more abstraction representation of the destination. I think reusing much of the AppHistoryEntry properties makes sense, but I have some questions for each of them:
url: OK, well, this is still obviousgetState(): this seems fine and useful to includekey: For push navigations, shouldkeybe the future key, or should it maybe benull? This is clearly a must for traverse navigations, and is easy to compute for replace navigations.id: should this even be included? Is it useful to make the browser figure this out early?index: a few options...- Don't include this
-1for push navigations, accurate index for other navigationsappHistory.current.index + 1for push navigations, accurate index for other navigations
sameDocument: If you callevent.respondWith(), should this change, or should it always reflect the "original" navigation? (AppHistoryEntry.sameDocument #70)
Activity
tbondwilkinson commentedon Apr 16, 2021
Thoughts:
domenic commentedon Apr 16, 2021
I'd love to hear more cases for using key and id (for pushes) in a navigate handler. I dislike the special case of making them null for pushes, but having real use cases would help me justify fixing that. Otherwise, the path of least resistance for spec/implementation is to probably leave them null.
tbondwilkinson commentedon Apr 16, 2021
I've seen a few use cases of storing the key so that you can detect when the state changes away and take some action. But perhaps they could set up those listeners directly on the entry?
If we're reasonable sure no one wants to correlate an in-progress entry with a serialized-entry, then I think they might not be necessary.
dvoytenko commentedon Apr 22, 2021
I think it should be whatever
appHistory.navigate()accepts. I'd think of it as a not-yet-materialized history entry, so I don't think it'd have anidyet or akey(unless thekeyhas been provided in thenavigate()call).domenic commentedon May 27, 2021
I started working on a PR to add
keyto"traverse"navigations. However then I thought that for traverse navigations,key/id/indexare all on equal footing, and probably we should include all of them if we're going to include any of them. Hmm.Maybe exclude
indexbecause it's really about the entry that lives inappHistory.entries(), whereas we're trying to say thate.destinationis not the entry?Or maybe
e.destinationshould be either anAppHistoryEntry(for traverse) or anAppHistoryDestination(for push/replace/reload)? Reload being on that side feels a bit weird but it seems necessary sinceappHistory.reload({ state: newState })meanse.destination.getState()needs to be different fromappHistory.current.getState()...Expand AppHistoryDestination
Expand AppHistoryDestination
Expand AppHistoryDestination
domenic commentedon Jul 28, 2021
I split the remaining discussions into #138 and #139. In both cases I am pretty happy with the status quo but they are just tracking issues to make sure we can gather feedback if people disagree.