Skip to content
This repository has been archived by the owner on Sep 1, 2021. It is now read-only.
Demetrios Skamiotis edited this page Jul 20, 2020 · 17 revisions

@guardian/types

Dealing with all the ways an article can look.

This section aims to decip[her and discuss the types within apps-rendering.

Types of articles are defined and quantified centrally to be formatted consistently across apps and dot-com rendering https://github.com/guardian/types

This sets out the type definitions which allows us to refer to specific types of articles in our code base.

We can see a variety of Types used in Apps-Rendering - here

1. Types Defined: Defining and categorising the articles

We have 'Types' of articles such as: live, media, analysis, comment and more.

In order to apply the appropriate format/styling for specific articles we first need to look format.ts here

Each article is a **type**.

Defined in CAPI-Live as: "id": "type/article",

// ----- Types ----- //

const enum Pillar {
    News,
    Opinion,
    Sport,
    Culture,
    Lifestyle,
}

const enum Design {
    Article,
    Media,
    Review,
    Analysis,
    Comment,
    Feature,
    Live,
    Recipe,
    MatchReport,
    Interview,
    GuardianView,
    Quiz,
    AdvertisementFeature,
    Interactive
}

const enum Display {
    Standard,
    Immersive,
    Showcase,
    NumberedList,
    Column
}

interface Format {
    pillar: Pillar;
    design: Design;
    display: Display;
}


// ----- Exports ----- //

export {
    Pillar,
    Design,
    Display,
    Format,
}

Here Enums are used more here

Creating a create a set of distinct cases

How is a 'type' detected?

  • A rendering request arrives to apps-rendering, within item.ts
  • CAPI data is parsed in:
const fromCapi = (context: Context) => (request: RenderingRequest): Item => {
  • checking CAPI data for appropriate tag id: The hasSomeTag() function looks at the tags ID within CAPI for the and returns a Boolean value if present
const hasSomeTag = (tagIds: string[]) => (tags: Tag[]): boolean =>
    tags.some(tag => tagIds.includes(tag.id));
  • An example of an Opinion article: A Boolean value is generated through the hasSomeTag()
const isComment =
    hasSomeTag(['tone/comment', 'tone/letters']);
  • In this case the if isComment returns True:
else if (isComment(tags)) {
        const item = itemFieldsWithBody(context, request);
        return {
            design: Design.Comment,
            ...item,
            pillar: item.pillar === Pillar.News ? Pillar.Opinion : item.pillar

We can see design set to design: Design.Comment

  • Now we categorised the article as a type we are able to apply designs to it
  • Within img.ts we can apply specific styling for that particular type of article. This means different types of articles can have specific design parameters for each.

for example:

const styles = (role: Option<Role>, format?: Format): SerializedStyles => {
    const backgroundColour = () => {
    switch (format?.design) {
        case Design.Media:
            return neutral[20];
        case Design.Comment:
            return neutral[86];
        default:
            return neutral[97];
    }
    };
    // const backgroundColour = format?.design === Design.Media ? neutral[20] : neutral[97];
    return pipe2(
        role,
        map(imageRole => imageRole),
        withDefault(Role.HalfWidth),
    ) === Role.Thumbnail ? css`color: ${neutral[60]};`
        : css`
            background-color: ${backgroundColour()};
            ${darkModeCss`background-color: ${neutral[20]};`}
            color: ${neutral[60]};
        `;
}

This specific part of the code needs further inspection: switch (format?.design) { case Design.Media:

format.design Is accessing the property Design on the Object format.

interface Format {  `<<<< Object Format`
    pillar: Pillar;
    design: Design;  `<<<< Property Design`
    display: Display;
}

2. The types (programatically) that we have defined within format.ts

Using an enum is simple: just access any member as a property off of the enum itself, and declare types using the name of the enum:

// ----- Types ----- //

const enum Pillar {
    News,
    Opinion,
    Sport,
    Culture,
    Lifestyle,
}

const enum Design {
    Article,
    Media,
    Review,
    Analysis,
    Comment,
    Feature,
    Live,
    Recipe,
    MatchReport,
    Interview,
    GuardianView,
    Quiz,
    AdvertisementFeature,
    Interactive
}

const enum Display {
    Standard,
    Immersive,
    Showcase,
    NumberedList,
    Column
}

interface Format {
    pillar: Pillar;
    design: Design;
    display: Display;
}


// ----- Exports ----- //

export {
    Pillar,
    Design,
    Display,
    Format,
}

Rather than using primitive types such as (number, string, boolean) we are defining the types ourselves. const enum Design is in effect stating:

  • Desing can only be of type media comment live Now what makes this slightly less obvious is the fact that we are defining these 'types' however it is unclear what they are. These types are deciphered and detected at the point of apps-rendering reading and detecting the tagId from CAPI (as described above).

If we take the example of Comment type we can follow the path outlined in section 1. So in essence we are saying: Does the article have a tagID of tone/comment making it a comment article.