Add AMP support to our starter theme

Although Frontity supports AMP, our current start theme (mars-theme) doesn’t. We should fix that.

I think that we should add not only AMP for posts and pages, but for all the possible urls, as long as a /amp is added at the end.

Instead of creating a new entry-point at /src/amp/ I’d rather use state.frontity.mode === "amp" so it’s easier to understand for beginners.

This requires that we end our html2react library first to be able to change the content HTML from WordPress for things like images and iframes, removing scripts and so on.

[ataylorme]

This sounds great @ataylorme, how can we help you? We could add a guide for Pantheon in the Installation & Deploy documentation.

@Poliuk I think that would be a great end goal. I think the next step for me is to create a proof-of-concept.

In order to use Frontity, a Node installation is required

Pantheon does not have Node support so I will look at doing WordPress on Pantheon and Frontity deployed elsewhere. We use Google Cloud Platform for our infrastructure so I would prefer to use their Cloud Functions.

I’ll start with things locally. Where I could use help from you is when it is time to deploy Frontity to GCP and “go live” with the proof of concept.

A doc similar to the deploy on Now for Google Cloud Functions would be helpful.

I can take what I learn and help with that Doc first. If things work then we can expand into adding Pantheon to your docs and Frontity to our docs.

[ataylorme]

@luisherranz thank you for the detailed reply.

We also see an opportunity for another gutenberg2react library as well, were one block relates to one React in component in your theme. But we are in the early days,

I would love to use the same component to build the block for Gutenberg/the back-end and on the front-end. The issue now is that the WordPress REST API exposes the rendered HTML, not the block data. The block attributes aren’t always exposed to the server (link). I think ideally the REST API would serve up the block attributes (for example, the text and citation for a block quote) to be consumed by a front-end client.

Maybe it’s worth to note that html2react is not meant to be a HTML to AMP transformer only, it is also useful for many other things. For example, adding native lazy load support to the images, your own React implementation of WP galleries and so on.

I totally understand 😄 that there is much value in a way to convert HTML to React (AMP aside).

The WordPress AMP plugin already transforms the HTML to be AMP valid (images to AMP images, galleries block to AMP carousel, etc.). As that plugin evolves support for more blocks will continue. The idea of consuming the already processed AMP HTML appeals to me.

Your example of return state.frontity.mode === "amp" ? <Content html={content.amp} /> : <Content html={content.rendered} /> seems much simpler to me than maintaining a transformer for block galleries to AMP carousel when the AMP plugin already provides it, though you may already have plans to make all components of html2react AMP aware, like the Image component is.

Overall, Frontity looks great and I will explore it, especially as it continues to develop.

I am on the DevRel team at Pantheon and doing a proof of concept workflow for creating Frontity sites on Pantheon seems very interesting. Happy to collaborate there if it seems interesting to you as well.