Feast "thrasher" component

[tomrf1]

Background

The Feast thrasher is displayed on fronts to advertise the Feast app.
Currently it is implemented as an interactive atom in the interactives repo: https://github.com/guardian/interactives/tree/main/thrashers/feast-ny-thrasher

It is added in the Fronts tool as a "snap link" using the CAPI url:

The flow for updating it is:

1. Build (html/css/js) locally and publish to S3
2. CAPI picks this up as an atom
3. On web, the html/js is inserted into the front container using dangerouslySetInnerHTML
4. On apps, MAPI returns the url of a page with the interactive atom and it is rendered in a web view inserted into the Front

Problems with this approach:

1. Bad Developer Experience compared with working on dotcom-rendering. E.g. for the web we cannot reuse dynamic/interactive components from Source/DCAR, like the Ticker.
2. Security concerns about inserting arbitrary js into fronts

We'd prefer to build + maintain thrasher components in dotcom-rendering, for use by web and apps.

This change

Adds a new component, FeastThrasher. Includes a storybook entry.
The component looks broadly the same, though it now aligns better with the front layout.

This is served as a stand alone page from a new DCR endpoint, /AppsComponent/thrasher/feast. This is a very minimal page for use by the apps so that they can render it in a webview, just as we currently do for the interactive atoms. It includes necessary fonts, meaning we no longer need the font-face definitions.
We'll need changes to Frontend and Router to expose this endpoint.

For now nothing will actually use this component.
Future PRs will:

1. change dotcom-rendering to use the FeastThrasher component directly from the FrontLayout, instead of using an interactive atom.
2. change MAPI to return the new url (https://api.nextgen.guardianapps.co.uk/component/thrasher/feast?dcr=apps) for use by the apps. It's likely there will be some styling fixes needed for apps compatibility, but we need to integration test to get to that point.

Later we should also consider how to improve how this is configured in the Fronts tool. But to begin with we can continue using the old snap link as an indication that the FeastThrasher should be used.

Testing

I tested how it looks in a front by temporarily adding code to the FrontLayout (see commit) -

Desktop:

Tablet:

Mobile:

[github-actions]

Deploy build 24785 of dotcom:rendering-all to CODE

All deployment options

• Deploy build 24785 of dotcom:rendering-all to CODE
• Deploy parts of build 24785 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[tomrf1]

this could just be a GET endpoint, not sure how much it matters

[tomrf1]

We might want to POST a payload in future, if/when we make the copy and image configurable

[JamieB-gu]

Looks great! A few comments and questions.

[JamieB-gu]

You may want to use the image optimiser to make these images more responsive to different screen sizes and pixel densities? Given this isn't live yet, this could be done in a follow-up change.

dotcom-rendering/dotcom-rendering/src/lib/image.ts

Lines 44 to 51 in f912e23

	/**
	* Generates a URL for calling the Fastly Image Optimiser.
	*
	* @see https://developer.fastly.com/reference/io/
	* @see https://github.com/guardian/fastly-image-service/blob/main/fastly-io_guim_co_uk/src/main/resources/varnish/main.vcl
	*
	*/
	export const generateImageURL = ({

[tomrf1]

These urls are copied over from the existing thrasher in the interactives repo. I'll take a look at the optimiser

[tomrf1]

I guess one of the benefits of moving it into dotcom-rendering is that we get to reuse features like this!

[github-actions]

Hello 👋! When you're ready to run Chromatic, please apply the run_chromatic label to this PR.

You will need to reapply the label each time you want to run Chromatic.

Click here to see the Chromatic project.

[gu-prout]

Seen on PROD (merged by @tomrf1 6 minutes and 47 seconds ago) Please check your changes!