Amphtml: FR: Seamless page transitions

Created on 23 Jan 2018  Â·  7Comments  Â·  Source: ampproject/amphtml

Developer impl
• Developer opts in/out links on a given page for managed page transitions

User-facing effect
• A more seamless page transition (no white flash, etc)
• Elements that are re-loaded get default loading animation.

AMP Impl
• Get URL
• Copy over script tags
• Replace body with new content ( @cramforce , would the entire document body be replaced, or just elements not common between the old and new doc?)
• pushState the URL (if in a viewer would need to coordinate) — handle back navigation, etc

Limitations
• Only works if the target page is AMP
• May only work on origin (though hopefully can get working from cache / in viewers)

/cc @cramforce @aghassemi @spacedino @choumx

All New Feature Navigation Soon DevX Feature Request components

Most helpful comment

I see this AMP component as also powering app shell capabilities. If the live regions of the AMP document are marked, then the app shell is essentially the document with the regions replaced with placeholders. This can then be cached as the app shell for subsequent launches of the app to then be populated with the regions in the requested URL, which is also either cached or which needs to be fetched from the network.

All 7 comments

So essentially origin-based version of A2A (https://github.com/ampproject/amphtml/issues/12496) ?
We should try to take the same implementation approach for both cases as much as possible. Maybe the only difference is the extra communication needed with the viewer to update its state of the current Url (which we need for Related-Content Infinite Scrolling anyway)

Same origin can avoid actual navigations / new iframes. So these might
actually be very different implementation. However, there would be a log of
shared code with the PWA code.

On Tue, Jan 23, 2018 at 10:11 PM, Ali Ghassemi notifications@github.com
wrote:

So essentially origin-based version of A2A (#12496
https://github.com/ampproject/amphtml/issues/12496) ?
We should try to take the same implementation approach for both cases as
much as possible. Maybe the only difference is the extra communication
needed with the viewer to update its state of the current Url (which we
need for Related-Content Infinite Scrolling anyway)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/12981#issuecomment-360031277,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeTzbM4txnAKc1maLACTxs3v9JXfIJks5tNsmtgaJpZM4RqMw1
.

Good point, Prototype for Related-Content Infinite Scrolling uses PWA infra. I guess this can be thought of a special case of the same thing, a new doc is loaded but instead of getting appended to the initial doc, it replaces it. @emarchiori

• Replace body with new content ( cramforce , would the entire document body be replaced, or just elements not common between the old and new doc?)

Perhaps there should be a way to declaratively identify the regions of the document that should get updated? The title and any metadata would be a given. The class attributes on the body and html would be another good default. But then there'd probably need to be a way to identify the nav menu that would need to be updated, and then the container for the content that changes. Or else do diffing on the entire DOM. This seems quite related to amp-live-list which is a very simple example of dynamically inserting content from another URL based on comparing the two DOM trees.

I see this AMP component as also powering app shell capabilities. If the live regions of the AMP document are marked, then the app shell is essentially the document with the regions replaced with placeholders. This can then be cached as the app shell for subsequent launches of the app to then be populated with the regions in the requested URL, which is also either cached or which needs to be fetched from the network.

One use case that has come up several times related to seamless page transitions and app shell is the ability for an AMP-first site to provide a persistent audio player (e.g. for a radio station) playing in a fixed bar at the bottom of the page. So I'd like to make sure that the implementation of seamless page transitions accommodates that use case, and that it's not just window dressing for a multi-page application. In other words, it should facilitate turning valid AMP pages into true single-page applications.

A library which may provide some inspiration for the API is barba.js.

For example, it is configured by adding certain data attributes to the page which mark the dynamic sections:

<body data-barba="wrapper">
  <!-- put here content that will not change
  between your pages, like <header> or <nav> -->

  <main data-barba="container" data-barba-namespace="home">
    <!-- put here the content you wish to change
    between your pages, like your main content <h1> or <p> -->
  </main>

  <!-- put here content that will not change
  between your pages, like <footer> -->
</body>

It's a similar idea to amp-next-page v1.0 actually.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Download picture Download  Â·  3Comments

cvializ picture cvializ  Â·  3Comments

gmajoulet picture gmajoulet  Â·  3Comments

aghassemi picture aghassemi  Â·  3Comments

edhollinghurst picture edhollinghurst  Â·  3Comments