Newsletter sign up pages

[alinaboghiu]

Abstract

The newsletter team wants to add sign-up pages for each editorial newsletter, using data from the newsletters api. These pages can be rendered entirely through frontend, but we'd prefer to use DCR.

As they will neither be articles nor interctives, there isn't a DCR endpoint to support them. Rather than build an endpont specifically for these pages, it seems better to build a more abstract endpoint that would accept a JSON post identifying the 'view component' (IE the React component describing a page template) and providing the data to use as props for that component.

drawbacks/challenges

Would need a maintainable way to ensure the page model (defined as scala classes) from frontend are in sync with the view component props (defined as Typescript interfaces?) in DCR.

worked example for planned newsletter detail page

1. Frontend receives request (eg get "/email-newsletters/sports-au"), routed to SignupPageController.scala
2. controller builds page model for the newsletter and serialises to JSON eg :

{
 "viewName": "newsLetterDetail",
 "data": {
   "newsletter": { "identityName": "sports-au", "name": "Guardian Australia Sport", ...},
   "recommendations":[
     { "identityName": "the-spin", "name":"The Spin", ...},
     { "identityName": "the-breakdown", "name":"The Breakdown", ...},
     ...
   ]
  }
}

3. controller posts json to new DCR endpoint
4. DCR parses the post data, identifying it as the payload for rendering 'newsLetterDetail' page
5. DCR returns the rendered HTML for a 'newsLetterDetail' component using the payload data as the props to frontend
6. frontend renders HTML output from DCR

e.g.

const newsletterDetailView = new SimplePageView ('newsletterDetail',NewsLetterDetailPageComponent)

const getSimplePageModelAndView = (body: SimplePagePayload): [SimplePageModel, SimplePageView] => {
	switch (body.viewName) {
		case 'newsLetterDetail':
			return [body.data, newsletterDetailView]
			break;
		default:
			throw new Error(`unrecognised viewName "${body.viewName}" in SimplePagePayload!`)
	}
}


export const renderSimplePage = (
	{ body }: express.Request,
	res: express.Response,
): void => {
	try {
		const [model, view] = getSimplePageModelAndView(body);
		const resp = view.render(model)
		res.status(200).send(resp);
	} catch (e) {
		// @ts-expect-error
		// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access
		res.status(500).send(`<pre>${e.stack}</pre>`);
	}
};

[alinaboghiu]

Following more thinking within the Newsletters team and chats with Dotcom, we are currently favouring the approach of using Composer to write the newsletter sign up pages and render them as articles using DCR, with a new NewsletterSignup layout.

This approach offers a few advantages:

• we can make use of the existing DCR /Article setup and avoid having to write a new endpoint
• the sign up pages with be easily editable by editorial and benefit from all other Composer features (takedowns, preview etc)
• existing interactive pages can carry on working as before, in parallel to the new sign up pages

Things to note:

• existing newsletter sign up pages that are already regular articles would change to the new format; if we wanted to support both we would need to introduce a new tag
• if ever we wanted the sign up page URL to be prettier, a redirect would have to be implemented
• we will need to update the capi client to use the version that includes the new NewsletterSignup article design so we can use it

Here are the designs for reference: https://www.figma.com/file/Nwcf5adXfG6hgHbwuD1OoQ/FINAL%3A-Single-signup-page-designs

[jamesgorrie]

This has generally been covered in this PR.