Description
A nice feature of the navigation API is that (unless we implement #9) data is almost never "lost". This solves a lot of problems we hear about today where history.state
is unreliable, or there's no way to easily know what your previous history entry was without keeping a side table, etc.
However, there is one place in the current design where data can be lost: if you use navigation.navigate(url, { replace: true })
, history.replaceState()
, or location.replace()
, the current navigation API history entry data disappears.
I say "kind of" because object references get replaced, not updated. So you could have a reference to the old NavigationHistoryEntry
object, which would allow you to access url
and getState()
. (But it's no longer in appHistory.entries()
.)
We could pretty easily keep these replaced NavigationHistoryEntry
s around and expose them. For example:
-
Each app history entry could have a
replaced
property that is null, or the entry it replaced. (This allows potentially chaining, e.g.navigation.currentEntry.replaced.replaced.replaced
.) This lets you access them forever. (Is this a problem for memory usage?) -
The
currententrychange
event could have areplaced
property which contains the replacedNavigationHistoryEntry
. This lets unrelated parts of the code (i.e., not the code doingnavigation.navigate(, { replace: true })
) grab important data as necessary.