-
Notifications
You must be signed in to change notification settings - Fork 1
Types
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
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
- 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;
}
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.