feat: add basic, do nothing, deeply read agent

[jamesgorrie]

Co-authored-by: Ioanna Kokkini [email protected]

Part of: https://github.com/guardian/dotcom-rendering/issues/5664

Adds the DeeplyRead agent data (currently empty) to the DotcomRenderingDataModel.model when posting to DCR.

This PR aims to decide on the model we should use to interface with DCR.

It also simply implements attaching that data to the model, which we will refine as patterns become more apparent by adding more examples (which we know are coming).

DCR interface

Naming

We have use MostPopular to indicate that section of the page in DCR, which can then be populated with different types of data e.g.

• Deeply read
• Most viewed
• Most viewed in section
• ...

Instead of coming up with a new name, which feels like it would just proliferate things further, this further defines things, is more intentional, and hopefully moves in a direction of less ambiguity.

Adding it to the mostPopular prop indicates to DCR this is where is should go on the page. I image we could use something similar for onwards.

Return type

As DCR already knows how to render OnwardCollectionResponse so we are using this.

Most comments & shared

As we know the plan is to remove these as soon as we have a better alternative (Deeply read), we didn't want to add this to the model.

In the short run, if this model is something we want to support, we could have a mostPopularSupporting or similar, as we call this MostViewedFooterSecondTierItem in DCR.

---

Getting the data onto the model

This is the least important as part of this PR and is likely to change as it doesn't affect the interface with DCR.

1. route
2. ArticleController fetches deeplyReadData
3. deeplyReadData is passed to DotcomRenderingService.getArticle

At this point we explored two options:

1. deeplyReadData is passed to DotcomRenderingDataModel.forArticle and other similar methods, and drilled through those methods
2. we copy the data onto the model fetched from DotcomRenderingDataModel.forArticle

The latter seemed simpler better reflects what we are doing which attaching request level, rather than item level data to send to DCR, and avoided massive code changes from prop drilling.

Global information like this seems to have been done by calculating it on the DotcomRenderingDataModel.apply, but including the agent at this level felt like too much of a coupling.

Another option to explore would be to create a new model, DotcomRenderingGlobalData or similar, and stitch them together before posting it to DCR. I think a clearer pattern will become more obvious adding some more examples, as we know we're going to. This implementation shouldn't affect how we interface with DCR.