https://github.com/WICG/proposals/issues/20 Skip to content Sign up * Why GitHub? Features - + Mobile - + Actions - + Codespaces - + Packages - + Security - + Code review - + Project management - + Integrations - + GitHub Sponsors - + Customer stories - + Security - * Team * Enterprise * Explore + Explore GitHub - Learn & contribute + Topics - + Collections - + Trending - + Learning Lab - + Open source guides - Connect with others + The ReadME Project - + Events - + Community forum - + GitHub Education - + GitHub Stars program - * Marketplace * Pricing Plans - + Compare plans - + Contact Sales - + Nonprofit - + Education - [ ] [search-key] * # In this repository All GitHub | Jump to | * No suggested jump to results * # In this repository All GitHub | Jump to | * # In this organization All GitHub | Jump to | * # In this repository All GitHub | Jump to | Sign in Sign up {{ message }} WICG / proposals * Watch 36 * Star 48 * Fork 1 * Code * Issues 15 * Pull requests 0 * Actions * Projects 0 * Security * Insights More * Code * Issues * Pull requests * Actions * Projects * Security * Insights New issue Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username [ ] Email Address [ ] Password [ ] [ ] Sign up for GitHub By clicking "Sign up for GitHub", you agree to our terms of service and privacy statement. We'll occasionally send you account related emails. Already on GitHub? Sign in to your account Jump to bottom A new history API, "app history" #20 Closed domenic opened this issue Feb 2, 2021 * 6 comments Closed A new history API, "app history" #20 domenic opened this issue Feb 2, 2021 * 6 comments Labels repo_adopted Comments @domenic Copy link @domenic domenic commented Feb 2, 2021 * edited Introduction The web's existing history API is problematic for a number of reasons, which makes it hard to use for web applications. This proposal introduces a new window.appHistory API, which is more directly usable by web application developers to address the use cases they have for history introspection, mutation, and observation/ interception. The proposed API layers on top of the existing API and specification infrastructure, with well-defined interaction points. The main differences are that it is scoped to the current origin and frame, and it is designed to be pleasant to use instead of being a historical accident with many sharp edges. Some notable features: * Allow easy conversion of cross-document navigations into single-page app same-document navigations, without fragile hacks like a global click handler. * Provide a uniform way to signal single-page app navigations, including their duration. * Provide a reliable system to tie application and UI state to history entries. (Better than the existing history.state.) * Provides reliable events for notifying the application about navigations through the list of history entries, which they can use to synchronize application or UI state. (Better than the existing popstate and hashchange events.) Read the complete Explainer. Feedback We'd love to hear from the community of developers as to whether this sounds like a worthwhile direction to explore, and in particular whether we should migrate it to the WICG for further discussion in its own dedicated repository. For any general feedback or questions on the idea, especially any support for developing the idea, please use this thread. For specific technical questions or suggestions on the API, file issues on WICG/ app-history where we can work through them in more detail. (Hopefully such questions can move to a dedicated WICG repository once we get general support.) The text was updated successfully, but these errors were encountered: 28 1 [?] 12 9 This was referenced Feb 2, 2021 New history event proposal #6 Open New history event proposal whatwg/html#5562 Open Should ARIA provide better support for routing in single-page applications? w3c/aria#1353 Open Scoped Web History API whatwg/html#2992 Closed beforeunload for post-pushState/replaceState navigations whatwg/html# 2961 Open History API: history.pushState/popState should reflect closing-page state instead of opening-page state whatwg/html#4866 Open Request for feedback on new browser API proposal ("app history") ReactTraining/history#855 Open @frehner Copy link @frehner frehner commented Feb 2, 2021 Whew, finally read through the complete explainer. Thanks for such an exhaustive writeup - I'm not sure I understood it all on my first reading, so I'll probably have to come back and read it a couple times more to really get it, but it is really promising. This proposal is exciting, and would certainly remove an issue that the whole single-spa community has to deal with, namely getting multiple application routers to be able to communicate with each other. (Currently the library itself has to monkeypatch history.pushState etc., as well as fire events more frequently than the browser does in order to get things working.) I would love to see this get officially picked up and started down the process of refinement and browser adoption. Awesome work [?] [?] 1 @TheMcMurder Copy link @TheMcMurder TheMcMurder commented Feb 2, 2021 I like the approach. It feels a lot more intentional and focusing on applications rather than pages. This would be a significant help in building complex web applications and could help bridge some the divide between the web as a platform for applications and other platforms like iOS and android. I would love to see this move forward. [?] 1 @Yay295 Copy link @Yay295 Yay295 commented Feb 3, 2021 Some notes while reading through the explainer: --------------------------------------------------------------------- appHistory.currentEntry; appHistory.updateCurrentEntry(); appHistory.pushNewEntry(); These seem a bit more wordy than necessary. I think appHistory.current; appHistory.update(); appHistory.push(); would be just as understandable, and shorter. Alternatively instead of appHistory.updateCurrentEntry, having an update method on the history entry itself might be even better. So appHistory.current; appHistory.current.update(); appHistory.push(); This would allow you to update any history entry though, not just the current one, which might be okay, but might not if the URL is changed. Though even that could be okay if it's a future entry and not a past entry, and an exception culd be thrown for a past entry. --------------------------------------------------------------------- Being able to use the object spread operator on history entries would make some things more readable. For example this line from the explainer for URL fragment navigation appHistory.pushNewEntry({ url: urlWithFragment, state: appHistory.currentEntry.state }); could be appHistory.pushNewEntry({ ...appHistory.currentEntry, url: urlWithFragment }); --------------------------------------------------------------------- For the navigation event, how would userInitiated work? If you go back far enough, every action is user initiated. The only things I can think of that might be considered otherwise are navigations that happen on load, or on a timer. Is appHistory.currentEntry still the current/previous entry at this point? A common scenario in web applications with a client-side router is to perform a "redirect" to a login page if you try to access login-guarded information. This should be handled by the server. It might be nice to do it on the client for convenience, but I think there needs to be a warning about using it only on the client. For the currententrychange, why does it only react to appHistory.currentEntry changes if its url or state changes? What about its other properties? --------------------------------------------------------------------- We're still having some discussions about making appHistoryEntry.state into something more structured, like a key/ value store instead of an arbitrary JavaScript value. I don't know what the discussions so far have been, but I think keeping it as a JavaScript value is cleaner to use. 2 @alvinometric Copy link @alvinometric alvinometric commented Feb 3, 2021 If we don't want to intercept cross-origin navigations and let the browser handle those normally, why not disable the API altogether for these cases ? I guess what I'm saying here, when there's space to abuse something, it will be abused @yoavweiss Copy link Collaborator @yoavweiss yoavweiss commented Feb 3, 2021 Thanks all! This seems to have a bunch of support here and elsewhere. I spun up a new repo for this at https://github.com/WICG/app-history Happy incubating! :) [?] 2 @yoavweiss yoavweiss added the repo_adopted label Feb 3, 2021 @domenic domenic mentioned this issue Feb 3, 2021 Bikeshedding "entries" WICG/app-history#1 Open @domenic Copy link Author @domenic domenic commented Feb 3, 2021 Thanks all! I'll close this out now, and work on porting over the issues to the new repo. @domenic domenic closed this Feb 3, 2021 Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Assignees No one assigned Labels repo_adopted Projects None yet Milestone No milestone Linked pull requests Successfully merging a pull request may close this issue. None yet 6 participants @domenic @yoavweiss @frehner @TheMcMurder @alvinometric @Yay295 * (c) 2021 GitHub, Inc. * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time. You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.