Bringing back currentchange, or maybe change in general

[domenic]

We removed currentchange in #125 due to lack of use cases. #14 has some discussion.

Since then a couple of use cases have come up for currentchange:

• Providing a clear point in time when, even if the transition is not finished, the current entry/URL has updated. This could be used to kick off processes which are independent of the transition, e.g., sending certain types of analytics, or updating parts of your UI, or similar. Stated another way, this gives you an immediate signal that the navigate event was not canceled.

• Relatedly, easing the migration from popstate and hashchange. Codebases today might want to not embrace the full app history paradigm of the navigate event and converting cross-document navs to same-document, but still get a more reliable change event.

This currentchange event would fire whenever either appHistory.current changes value, or when appHistory.current gets updated, e.g. by history.replaceState() or appHistory.updateCurrent().

It would probably be useful if the event object contained a property like event.previous or event.from so you could compare to the old value? But that's a bit unusual for change events on the web platform, so maybe not.

---

But then I was thinking, why not go further? We could fire an event when anything in entries() changes. In particular, this event would fire if entries from far back in the list disappear (due to browser policies on maximum number of entries, or the user clearing their history). Or if new entries grow in the back of the list (due to #45). Or if we allow other modifications like #9.

The use cases this would enable, in addition to the above, are:

• Displaying a live-updating in-page history navigation list. (The explainer kind of mentions this case, but seems like I forgot to update it when we removed currentchange: "In combination with the following section, the entries() API also allows applications to display a UI allowing navigation through the app history list.")

• All the use cases that the per-entry dispose event is used for, but perhaps in a cleaner fashion. See also discussion in An event for when entries disappear for other reasons than forward-pruning #72.

Similarly the event object here could contain e.g. addedEntries, removedEntries, updatedEntries. Or we could have the developer save the old entries list and compare manually.

[samthor]

Echoing my summary from chat, I think it'll be hard to describe exactly when users should add events handlers to an entry (or perhaps a number of entries created on page load, e.g., because of a reload). The current example in the spec doc just shows adding entries after programmatic navigation, which implies you know the nav is coming.

This becomes clearer to me in a centralized change/currentchange event.

[domenic]

Split off just the remaining part (a general "any entry changed" event) into #205