Define the "layout" nodes

[adgad]

Problem

We currently publish "layout" components through the use of the <experimental> tag. These components are not defined in the Content API schema, but are based on a generic container/slot model that was created as part of the Rich Journalism project in 2018. These used <div>s with data attributes, to indicate that they do not have semantic meaning and are purely visual.

Rich Journalism Modelling document

As part of the Spark project, these were consolidated into a small number of editorial components (which did have semantic meaning). As there was no Customer Products/Storytelling team available at the time, these components would continue to render out using the same

structure.

Content Platform open issue

When creating the AST, we would ideally like to model these components to capture the semantic meaning behind them, and let consumers choose how to render them.

[adgad]

I've created a Spark Staging article with all the possible layouts: https://spark-staging.ft.com/editor/9c2f528e-e46c-48c1-a922-bf4d12b4ef30?

https://api-t.ft.com/internalcontent/9c2f528e-e46c-48c1-a922-bf4d12b4ef30

Challenge 1: for most of these layouts, there is no discernible information in the API output that lets us know what component is being used. I would expect these to have `data-layout-name="info-box" as an example, but they do not (possibly because FT.com didn't have styling for those names).

This will make it hard (impossible??) to "fix" these components in a bodyXML => bodyAST function.

[adgad]

First attempt:

interface InfoBox <: Parent {
  type: "infoBox",
  title: string,
  width: "full" | "half"
  children: [Image | Paragraph]
}

interface Comparison <: Parent {
  type: "comparison",
  title: string,
  children: [ComparisonItem]
}

interface ComparisonItem <: Parent {
  type: "comparison",
  children: [Image | Paragraph]
}

interface ImagePair <: Parent {
  type: "imagePair",
  children: [ImagePairItem]
}

interface ImagePairItem <: Parent {
  type: "imagePairItem",
  children: [Image | Paragraph]
}

interface Timeline <: Parent {
  type: "timeline",
  title: string,
  children: [Image | TimelineEvent]
}

interface TimelineEvent <: Parent {
  type: "timelineEvent",
  date: string,
  children: [Image? | Paragraph]
}

interface InNumbers <: Parent {
  type: "inNumbers",
  title: string,
  children: [Image | BigNumber]
}

Questions:

• most of these components in Spark can in theory accept any children (e.g. I could put a recommended link inside a timeline. I don't know if they ever do in practice? Should we limit it??
• "in numbers" actually doesn't use BigNumber (it uses a heading/paragraph 😬 ). I think BigNumber makes sense to use here. If not, maybe a new Number node.

[adgad]

Decision:
Since we would be unable to distinguish between all the layouts from the XML, we are going to start with a more minimal set of layouts:

interface CardLayout extends Parent {
	type: "card-layout"
	title?: string,
        width: "full" | "half"
        children: CardSlot[]
}
interface CardSlot extends Parent {
	type: "card-layout"
        children: [ImageSet?, ...Paragraph]
}

interface Timeline <: Parent {
  type: "timeline",
  title: string,
  children: [ImageSet, ...TimelineEvent]
}

interface TimelineEvent <: Parent {
  type: "timelineEvent",
  date: string,
  children: [ImageSet?, ...Paragraph]
}

CardLayout will basically encompass everything we have now in Spark, except Timelines which we can deduce a model for.

We can then iterate and add newer models for things like ImagePair, Comparison etc later on, and any old articles will fall back to using the default CardLayout.