fetch newsletter layouts

[dblatcher]

What is the value of this and can you measure success?

The /emai-newsletters page currently uses hard-coded data in the DCR repo describing how the newsletters should be arranged for each Edition (UK, US, Aus, International).

Any change to the layouts require a PR into DCR, but the data could instead be managed from the existing newsletters tool and published on the newsletters api, allowing editorial to self-serve for changes - see guardian/newsletters-nx#328

This PR has fronted provide the data on the page model to DCR so that DCR can use it instead of the hard coded version.

What does this change?

• Adds a method to fetch newsletter layout data (Map of Edition id to newsletter layout )from the newsletters-api, and cache it using the existing NewsletterSignupAgent
• Adds the an optional "layout" object to the DotcomNewslettersPageRenderingDataModel
• When building the DotcomNewslettersPageRenderingDataModel for a request for the /email-newsletters page, the layout for the Edition of the request is included in the model.

Test

Run DCR (this branch - guardian/dotcom-rendering#12795 ) and frontend locally and open http://localhost:3000/email-newsletters

The layout data used will be from https://newsletters.code.dev-guardianapis.com/api/layouts - (if there is no layout defined for the Edition you are viewing, DCR will fallback to its default layout including all live newsletters)

Checklist

• Tested locally, and on CODE if necessary
• Will not break dotcom-rendering
• Will not break our database – if updating CAPI, updated and committed the database files
• Meets our accessibility standards
  • Tested with screen reader
  • Navigable with keyboard
  • Colour contrast passed

[github-actions]

Deploy build 3229 of dotcom:frontend-all to CODE

All deployment options

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

---

From guardian/actions-riff-raff.