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 be an AppHistoryEntry for "traverse" navigations #139
Description
Spinning off from #97, re-summarizing based on the current state of things. Orthogonal to #138.
For "traverse" navigations, we currently have event.destination in the navigate event being a static snapshot saying where we're heading. But it could just as easily be the AppHistoryEntry we're heading to. The AppHistoryEntry API is a superset of the AppHistoryDestination API.
The differences (benefits?) would be:
- If it's an
AppHistoryEntry, it will be "live". If you hold on to it, itsurlandgetState()can update, and itsindexmight become -1 if it gets kicked out of the app history list. - If it's an
AppHistoryEntry, you could attach event handlers for the per-entry events
The drawbacks would be:
- It might be confusing that
event.destinationis live for traverse navigations but a static snapshot for push/replace/reload navigations. - The reload case is especially tricky. We can't use
AppHistoryEntryfor reload navigations because givenappHistory.reload({ state: newState }), we need to haveevent.destination.getState()return the new state, not the old state of theAppHistoryEntry. So although you might expect to get a realAppHistoryEntryfor reloads, since like a traverse they're going to somewhere that already exists, you wouldn't get one.
Overall, making this change doesn't seem that compelling to me, but I'd like to keep this tracking issue open to see if people have other ideas.
Activity
bathos commentedon Jul 28, 2021
As someone doing kill-then-resurrect navigate handling (cancel or reverse initial attempt, perform transition, finally “commit” the original nav if the transition succeeds), I appreciate the snapshot behavior. It allows keeping the original navigate event around for that last step, where we’re trying (typically) to recreate the original nav attempt to the extent possible. If it weren’t a snapshot, we’d have to make the snapshot manually. That’s not hard, but it’s not super obvious that you’d need to, I think; it seems like an avoidable booby trap?
(I suspect there are cases beyond this specific pattern, too, where people are likely to be attracted to just keeping a navigation event around for “recreating” after something does or doesn’t happen — e.g. in “discard unsaved changes” flows.)
Not a strong opinion — just some feedback about why I think the snapshot behavior provides a bit of harder-to-screw-it-up-by-accident safety (and sometimes also convenience).
domenic commentedon Nov 4, 2021
Let's stick with the snapshot behavior!
wycats commentedon Jun 24, 2022
The Ember framework team discussed the possibility of basing the next iteration of our router on the Navigation API in today's meeting, and we're overall extremely optimistic that it's the right direction.
From our perspective, as long as the AppHistoryDestination API is a subset of the AppHistoryEntry API and contains at least
keyandid, we're happy. 😄