At history.pushState
we can pass URL
history.pushState(stateObj, title, URL);
to change URL in browser without navigating away from page.
Could AMP implement it?
Ex.: In a SPA, an user select Tweets tab, and url change to /tweets
, then select Agenda and url change to /agenda
.
@cvializ worthy to keep in mind as part of stateful AMP pages.
I think some aspects of this FR are already implemented in amp-bind with the AMP.pushState
and AMP.popState
actions. https://amp.dev/documentation/components/amp-bind/?referrer=ampproject.org#modifying-history-with-amp.pushstate()
But I believe it only allows the back/forward buttons to update the state, the URL and title are not updated at this time
That's correct. Also we'd need viewer coordination to update title and hash.
+1 At BringFido, title/url updating on state change (when not being shown from an amp cache) is the last mission-critical thing we can't pull off in AMP.
The original API proposal: https://github.com/ampproject/amphtml/issues/9128#issuecomment-320332045
From an AMP-first perspective, many websites have a search/filter functionality which updates the URL so that it can be easily shared with filters pre-applied.
Similarly, all Shopify websites update the URL with ?variant={{variant.id}} so that when sharing a page with friends, the recipient auto-selects the proper variant.
If a user lands on a product page, clicks a new variant, and wants to share it with a friend, they'd likely share it by copying the address bar URL.
For websites that do URL updating, it does seem especially useful.
Is this intended on being implemented any time soon?
From what I gather above, it's currently deemed impossible?
Definitely possible, just hasn't been prioritized yet.
Similarly, all Shopify websites update the URL with ?variant={{variant.id}}
I think this can be done today with amp-list
and a QUERY_PARAM
variable substitution in the src
attribute, though it would fire a network request.
Most helpful comment
The original API proposal: https://github.com/ampproject/amphtml/issues/9128#issuecomment-320332045