Add RecipeBlockElement and related case classes for recipe data handling

[andresilva-guardian]

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

Recipe articles (e.g. food/2026/apr/27/pasta-bake-sumac-salad-prep-ahead-recipes-sami-tamimi) contain structured recipe data authored in Composer. This data is stored in CAPI as ElementType.RECIPE body block elements with a recipeTypeData.recipeJson blob, but we were silently discarding it, meaning DCR never received it.

We are making that structured data available to DCR, which is a prerequisite for rendering interactive recipe cards (ingredients, steps, timings, image, deep-links into the Feast app) inline in food articles.

We can measure success by verifying that RecipeBlockElement nodes are present in the FEArticle JSON payload for recipe articles (e.g. via the ?dcr=true debug view).

What does this change?

We only changed a single file: PageElement.scala.

New data model

We introduced two new case classes:

• RecipeFeaturedImage, the recipe hero image, with required fields url, mediaId, cropId, and optional fields source, photographer, caption, imageType, width, height, mediaApiUri.
• RecipeBlockElement, the top-level element extending PageElement, with a required id and optional title, description, featuredImage. The id is the stable recipe identifier used for Feast deep-links.

The model is intentionally minimal, exposing only the subset of fields DCR currently needs. If we need more fields, we should refer to the canonical schema at guardian/recipes-backend/schema/recipe-v3.json.

Data flow

We added a case Recipe => handler in PageElement.make(), which was previously missing (falling through to case _ => Nil). The recipeJson string from CAPI is parsed using Play JSON Reads derivation and mapped to a RecipeBlockElement.

flowchart LR
    A["CAPI\n(ElementType.RECIPE)"] --> B["recipeTypeData\n.recipeJson\n(raw JSON string)"]
    B --> C["Json.parse(json)"]
    C --> D["json.validate\n[RecipeBlockElement]"]
    D --> E["RecipeBlockElement\n(id, title, description,\nfeaturedImage)"]
    E --> F["FEArticle body blocks\n→ DCR"]

Loading

We also added RecipeBlockElement to isSupported so it passes the element filter and is included in the DCR payload.

Feast visibility

Feast visibility is determined entirely by the presence of a RecipeBlockElement. Any article with a recipe element is visible in Feast unless explicitly blocked via channels. There is no per-recipe flag for this.

Deployment order, DCR must ship first

DCR validates all incoming FEArticle payloads against an AJV JSON Schema (feArticle.json). The schema uses additionalProperties: false-style validation with explicit anyOf type discrimination, meaning any _type value not listed in the schema causes a hard validation error and returns a 500 for that article.

We must not merge this PR to main until the corresponding DCR PR (which adds RecipeBlockElement to feArticle.json and implements the recipe card renderer) has been deployed to PROD. The safe deployment order is:

flowchart TD
    A["1. Merge DCR PR\n(adds RecipeBlockElement to feArticle.json\n+ recipe card renderer)"] --> B["2. Deploy DCR PR to PROD"]
    B --> C["3. Merge this frontend PR\n(safe to merge now)"]
    C --> D["4. Deploy this frontend PR to PROD"]

Loading

Screenshots

No visual change on the frontend, this is a data pipeline change. The structured recipe data will be visible in the DCR payload (?dcr=true) for recipe articles once deployed.

Checklist

• Tested locally, and on CODE
• Will not break dotcom-rendering, see deployment order note above
• Any new test data/database files generated by tests are committed with this PR (the tests will fail in CI if you've forgotten to do this)
• Meets our accessibility standards
  • Tested with screen reader
  • Navigable with keyboard
  • Colour contrast passed

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1214429584331904

[github-actions]

Deploy build 6935 of dotcom:frontend-all to CODE

All deployment options

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

---

From guardian/actions-riff-raff.

[Divs-B]

The PR appears to have expected code for the Recipe element to flow to the frontend.

I have a few questions to clarify:

1. Could you please provide a screenshot of the logs that show the RecipeBlockElement correctly flowing for any recipe? (I do not have access to the frontend logs.)
2. Could you please confirm if we have any unit tests to ensure that we are not breaking upstream code for any mandatory data that the frontend might expect? For example, if a featured image object is present but lacks a cropId.
3. Are you logging any failures for any recipe element if the recipe itself is malformed? (I am sure it is not, but assuming.)

[Divs-B]

I am curious to check if there is reason behind these mandatory 3 fields only for available featuredImage? Are we having same schema in CAPI?

[Divs-B]

It appears that we are only seeking id and others are Optional. I trust this aligns with the requirement. However, for the sake of maintaining a minimal stack of knowledge for a recipe block element, could we also retain datePublished and author?