FR: Seamless page transitions

[ericlindley-g]

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

[aghassemi]

So essentially origin-based version of A2A (#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)

[cramforce]

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 ***@***.***> wrote: So essentially origin-based version of A2A (#12496 <#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 <#12981 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFeTzbM4txnAKc1maLACTxs3v9JXfIJks5tNsmtgaJpZM4RqMw1> .

[aghassemi]

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

[westonruter]

• 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.

[westonruter]

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.