currentchange is not suitable for measuring the time

[domenic]

After #46, appHistory.current updates synchronously, and thus currentchange fires synchronously, for all single-page navigations. So the example in the explainer which uses currentchange to measure the time is totally wrong.

This should probably be solved together with #14 and #33 but I wanted to note it separately since it's a serious bug in the explainer.

[tbondwilkinson]

A counter proposal I think would be a afternavigate (or navigateend or whatever) event, that is sent whenever a navigation is fully finished, that would have largely the same properties as the currentchange event but would have the added benefit of only firing after a navigation had fully settled. I think if we go this route, we would get rid of currentchange altogether, and changing the timing of the event I think actually makes it more broadly useful (since it's not just identical to navigate but without the respondWith capability).

[frehner]

Was talking with someone and the confusion around the timing of currentchange and the differences to navigate, so I remembered this issue.

Regarding a new event - would it just be easier to just add the timing information to navigatesuccess - since that event fires when respondWith() promises complete (unless it's been aborted), right?

[domenic]

Yeah, navigatesuccess has the appropriate timing for that. However per #33 we might want to expose the timing information in a completely different way; we'll see...