Skip to content

Latest commit

 

History

History
69 lines (44 loc) · 7.43 KB

2021-06-28-incubation-update.md

File metadata and controls

69 lines (44 loc) · 7.43 KB

Incubation Update: June 28, 2021

App history is happening! 🥳🥳🥳 Read on to find out what's new since last time.

Prototype implementation

We continue to prototype app history in Chromium, behind the Experimental Web Platform features flag. You can try it yourself by using the latest build of Chrome Canary and flipping the flag in chrome://flags.

And as of today, we feel that we've reached a milestone where people can seriously experiment with app history, and try to prototype real apps and libraries! We've implemented the core features of the proposal: introspection into the app history list, conversion of cross-document navigations into same-document navigations, and the appHistory.navigate() API. You can check out the following demos to see these in action:

(Note that unlike the last time you saw those demos, now the back button works.)

At this point it's easier to list what we haven't implemented, than what we have. The following APIs from the explainer are not yet in Chromium:

  • appHistory.reload()
  • appHistory.transition
  • appHistoryNavigateEvent.navigationType
  • appHistoryNavigateEvent.signal, and stop button integration
  • Integration of navigate events with accessibility technology
  • appHistoryEntry events
  • Performance timeline integration

Additionally, we have a number of open issues about updating to the exact spec semantics, especially in edge cases. Follow our progress in Chromium bug 1183545 and its BlockedOn issues!

Specification and tests

The specification continues to mostly track the prototype implementation. However, specifying goTo()/back()/forward() is proving tricky, due to shaky spec foundations around history traversal in general. We're taking care to stabilize the foundations beforehand, before building new features on top of them.

We also fixed an issue with the base navigation spec which was preventing us from confidently upstreaming our tests, since until recently the tests technically did not match the HTML spec. Now our tests are headed to the web platform tests repository, to better enable sharing with other browser vendors and with polyfill authors.

Design issues

Since last time, the substantial design changes worth noting include:

  • Specifying that any new navigation will interrupt an ongoing one, including firing abort on its event.signal property: #68
  • Adding appHistoryEntry.id alongside appHistoryEntry.key: #88
  • Renaming appHistory.navigateTo() to appHistory.goTo(), and combined appHistory.push() and appHistory.update() into appHistory.navigate(), both based on feedback from Mozilla: #84
  • Subsequently splitting out appHistory.reload() from appHistory.navigate(): #118
  • Introducing performance timeline API integration to replace the currentchange event: #125
  • Allowing multiple calls to appHistoryNavigateEvent.respondWith(): #126

We still haven't settled on solutions for URL-rewriting use cases or back-button prevention, but they remain on our radar. And the naming discussion for the whole API continues; we were considering renaming the API to window.navigation—Mozilla is especially enthusiastic—but haven't pulled the trigger yet due to concerns about it being confusing with window.navigator.

New design issues which have cropped up include:

  • Since appHistoryNavigateEvent.respondWith()'s semantics have changed, the respondWith() name is no longer very good: #94
  • How should someOtherWindow.appHistory.navigate()'s returned promise behave? #95
  • appHistoryNavigateEvent.destination currently contains only url, sameDocument, and getState(). Are there use cases for more? #97
  • How should appHistory.navigate(currentURL, { replace: false }) behave? #111
  • Should we expand the definition of appHistoryNavigateEvent.userInitiated? #127

Finally, we're contemplating the following additions based on what we've seen so far:

  • #101 is about allowing more powerful <a> navigations, e.g. <a href="..." navigateinfo="..." replace> or maybe even <a key="an app history key">.
  • #115 claims that we probably need to introduce the ability to modify an AppHistoryEntry's state, even without performing an intercepted navigation.
  • #124 discusses introducing a more first-class API for single-page app "redirects".

Note that these days we're maintaining a feedback wanted label, which lists all the issues where community feedback would be especially helpful.

Go forth and prototype

We've reached a new stage in the app history proposal, where we've got the core API implemented and now need to validate that it works for real apps and libraries. If you work on a router or history library, or a framework that manages those aspects, consider spinning up a branch to test out whether app history will help your users. Even if you don't want to fully buy into the navigate event lifestyle, consider sprinkling in a few uses of appHistory.entries(), using app history state instead of history.state, or enabling new experiences like making your in-page back button sync with the session history.

Similarly, if you have a hobby application, consider trying to use app history API directly so you can give us feedback. What works well? What works poorly? What's missing? Did you gain a new perspective on any of the feedback wanted issues?

In all such cases, the polyfill might be helpful. The author, @frehner, has been heavily involved in the app history repository, and although at this stage we can't guarantee it always matches the spec or Chromium behavior, as the spec and implementation firm up we do plan to collaborate more closely with @frehner on the polyfill to make it production-ready.