Add Storylines content to tag pages #15008

Georges-GNM · 2025-12-15T10:57:07Z

What does this change?

Part of the AI tag pages work. This adds the content to the tag pages model, enabling it to be passed through from the work in this frontend PR, implements the figma designs (available here although there’s also been some subsequent decisions not updated in the figma), and includes new storybook stories for testing.

Worth flagging at the outset that this is all behind a 0% experiment in frontend - if not in the test, frontend doesn't retrieve the needed content (just returning None). In January, we plan to start a 50% test on a limited number of pages; after which we'll determine if we want to keep the feature and deploy it on a wider number of tags.

It looks like a big PR, but it's meant to comprehensively deliver the feature (with the associated model, data transformation and rendering changes, which has also meant splitting this up is arguably not ideal). A significant portion of the diff comes from code which is either very similar to an existing component, or from schema changes/fixtures/storybook setup.

Chromatic tests only flagged one false positive for an existing component (change of the classname), so I'm fairly confident this doesn't affect existing styling.
  

What does this actually change?

We add the content type to the tag page model, based on the structure provided by the tool and correspondingly sent by frontend.

As a quick overview, we have:
-> content
---> array of storylines
----> in each storyline, an array of categories (e.g. key stories, opinions, deep reads)
-----> in each category, an array of articles, with the minimum data required to render them by DCR (headline, url, publication date, maybe byline, image data and if relevant, main media data).

The content gets rendered in the tag page layout just below the first container (thereby always showing the most recent articles on a given tag at the top of the page). The designs are inspired by the front page redesign, and notably the flexible general container, so the implementation has taken this into account and tried to reuse existing logic where possible.

We add two new components, StorylinesSection and StorylinesSectionContent.importable. The former provides the general structure of the section (it's very similar to the FrontSection component, particularly in terms of the style and grid setup, but slightly adapted and removing unnecessary logic).

The latter calls an enhanceAITagPageContent function to transform the data sent by frontend, turning the very basic article information we receive (headline, url, image/multimedia data) into the DCRGroupedTrails and DCRFrontCard shape. Based on the categories these articles are a part of, we can be deterministic in terms of how values need to be defined for a DCRFrontCard (e.g. for the format). Most of these front cards end up being part of the standard group in a trail, but the key stories category is a bit different: the image for that gets taken from the first (latest) article in the category, and each of the headlines get used as the "supporting content" on the left of the image.

Once we've got the data in shape, each of the categories in a storyline gets rendered as a flexible general container. These are individual containers mainly so we can add the title of the category before them.

For the most part this just uses the pre-existing logic, but some variations needed to be tweaked (e.g. the rendering of the key stories category in particular), and so we pass a boolean isStorylines through FlexibleGeneral and Card to enable this (and add a SupportingKeyStoriesContent component, similar to the supporting content component, but with enough notable differences). CardAge and feature card components (FeatureCard and FeatureCardAge) also get touched slightly, to ensure we display the age correctly (as the cards are displayed on an “archive” page, it feels important to indicate when the article was published).

The only piece of AI generated text, the titles of the storylines, get rendered at the top of the section. These are tabs that can be clicked on to switch stories, so we need this to be an island to enable the necessary javascript.

Few more points to note:

The storyline section has some text at the top left (under the "Storylines" container title), with a link that should point to further information - we've not settled on exactly where this is going yet, but I'd prefer to keep this text as is (and update the link in a subsequent PR) to keep a view of it as part of the design. In order to provide a valid link, I've pointed to the AI guidelines for now.
The bottom left of the storyline section (the standard "treats" position) makes use of the like/dislike feedback footer usually found in atoms. This is so we can try to get a bit more qualitative feedback from readers in the test. I've added the relevant component type to the thrift model and bumped the version of tracker.js to enable this (following this PR in Ophan)
The StorylinesSection and SupportingKeyStoriesContent components were copied from FrontSection and SupportingContent and then simplified for this situation. I removed as many unused props as possible, but kept some intentionally as we may want to use them in the future; happy to strip these out though if we’d prefer to keep things as concise as possible. (Notably flagging the toggleable and alignment props, respectively, despite the section not currently being toggleable and the supporting content alignment always being defined as vertical)

For future reference

It's possible we'll want to remove this code altogether, which should a straightforward process; mostly this should be a question of deleting the new components/files and following the trail of the isStorylines prop and removing references/uses, and I've added a couple of comments prefaced with AIStorylines in front of the few other lines we'd want to remove.

Screenshots

Category	Desktop	Mobile
Full page
Key stories
Opinions/Explainers
Deep Reads
Multimedia
Profiles

github-actions · 2025-12-15T11:11:33Z

Deploy build 403 of `dotcom:ab-testing` to CODE

All deployment options

From guardian/actions-riff-raff.

github-actions · 2025-12-15T11:14:35Z

Deploy build 23614 of `dotcom:rendering-all` to CODE

All deployment options

From guardian/actions-riff-raff.

github-actions · 2025-12-30T15:41:33Z

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.

domlander · 2026-01-07T17:04:25Z

This isn't a blocker, but I think hover state could be improved on the splash container:

No hover state on the tabs.
Hovering over the card but not the headlines uses the image overlay.

Screen.Recording.2026-01-07.at.17.00.34.mov

domlander · 2026-01-07T17:06:38Z

dotcom-rendering/src/components/Card/components/CardAge.tsx

 	isTagPage: boolean;
 	showClock?: boolean;
 	colour?: string;
+	storylinesStyle?: boolean;


I wonder if isStorylines might be a bit clearer, similar to isTagPage above. Will leave up to you.

Yeah, isStorylines looks a bit more in keeping with other props on card.tsx, will update that.

domlander · 2026-01-08T09:06:12Z

dotcom-rendering/src/components/Card/Card.tsx

+						alignment="vertical"
+						containerPalette={containerPalette}
+						fillBackgroundOnMobile={isFlexSplash}
+						storylinesStyle={storylinesStyle}


Is this the same?

storylinesStyle={true}

Effectively yep, will update that so it's more clear.

domlander · 2026-01-08T09:09:07Z

dotcom-rendering/src/components/FlexibleGeneral.tsx

 				mediaSize: avatarUrl ? 'large' : 'xlarge',
-				supportingContentAlignment:
-					supportingContentLength >= 4 ? 'horizontal' : 'vertical',
+				supportingContentAlignment: storylinesStyle


I would recommend extracting this. Nested ternary's can be harder to read.

domlander · 2026-01-08T09:11:35Z