appHistory.update async or not, and the effect on navigation cancellation

[frehner]

In the example section there is

// Updates the URL shown in the address bar, as well as the url property. `state` stays the same.
appHistory.update({ url });

// You can also explicitly null out the state, instead of carrying it over:
appHistory.update({ url, state: null });

// Only updates the state property.
appHistory.update({ state });

// Update both at once.
appHistory.update({ url, state });

which seems to indicate that it's not async. There is also the WebIDL format:

undefined update(optional AppHistoryEntryOptions options = {});
undefined update(AppHistoryNavigationCallback);

However, there is one place where it is written with await

use await appHistory.update({ state, url })

But the real reason for bringing this up is to understand better how appHistory.update and the navigate event are intended to work together:

If update is sync, then does that mean event.respondWith() has no effect and you cannot cancel an update with it? Would navigate event handlers need to differentiate between push and update in those cases? Or would it still work and just roll back the update at some future point, possibly firing the navigate event again?

Also, if update and push are different, does that open the door to potential mixups by developers mis-remembering which needs to be await-ed or not? (specifically regarding this section?)

Hopefully my questions make sense, and also I hope I didn't miss a section in the docs that explain this. 😃 Thanks!

(edit: This probably ties somewhat into the conversation happening in #19 as well)

[domenic]

Heya, great question. I think I've flipped back and forth on this a few times, which is what led to the current inconsistent state you noticed.

In general, the spec's current idea of making all navigations async so that they can be intercepted doesn't really work. We're figuring that out in #19, as you saw.

The latest thinking there is that, generally, we'll update the URL/state/current entry immediately, let the potentially-async navigate handler(s) run, and when those finish, fire some extra events, fulfill promises, etc. This gets more complicated for cases like the promise passed to respondWith() rejecting, or a navigation interrupting an existing ongoing navigation. See #19 (comment) for the full current plan.

I think, given that, we should probably make both update() and push() async, with the same type of semantics.

Although, see also the discussion #42 ...