Add appHistoryEntry.id and clarify object identity

[domenic]

Closes #7.

Would love a look from @tbondwilkinson in addition to @natechapin. With this in place I'll feel more comfortable speccing a basic AppHistoryEntry and appHistory.current.

[frehner]

The section explaining the differences between key and id is great. 💯

One thing that I just thought of, that probably isn't that important but I was curious about: does the AppHistoryEntry object reference stay the same in all instances? e.g.

const previous = appHistory.current
await appHistory.navigate({replace: true, state: ''})
const current = appHistory.current

console.log(previous.id === current.id) // false
console.log(previous.key === current.key) // true

console.log(previous === current) // ???

[domenic]

The plan is for the identity to match id. (Except in cases where that's impossible and doesn't make sense, like browser session restore.Well, probably we'll generate a new id even for those, now that I think about it. So it'll match 100% of the time.)

The explainer tries to talk about this in "The complete list of ways the current app history entry can change to a new entry are:" but maybe it'd be best to be more explicit...

[domenic]

TODO: talk about session restore in more detail. I think it should be fine to generate new IDs upon session restore (while keys stay the same).

[tbondwilkinson]

Overall looks great.

I think I would be a little surprised if IDs are regenerated upon session restore, because there are lots of caches you might have stored history-correlated resources that are preserved across a session restore

[domenic]

Hmm OK, that makes sense. We can probably make them stick around across session restore.