Skip to content
This repository has been archived by the owner on Sep 1, 2022. It is now read-only.

feat: migrate format from @guardian/types #220

Merged
merged 11 commits into from
Jul 13, 2021
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@

- [Modules](#modules)
- [`cookies`](#cookies)
- [`format`](#format)
- [`getLocale`](#getlocale)
- [`getSwitches`](#getswitches)
- [`isBoolean`](#isboolean)
Expand All @@ -39,6 +40,10 @@ The following modules are available:

API over `document.cookies`.

### [`format`](./src/format.README.md)

Types and enums related to editorial formats.

### [`getLocale`](./src/getLocale.README.md)

Get the user’s current location.
Expand Down
10 changes: 10 additions & 0 deletions src/format.README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# `format`

Types and enums related to editorial formats.

### Usage
jamie-lynch marked this conversation as resolved.
Show resolved Hide resolved

```js
import type { Theme, Format } from '@guardian/libs';
import { Pillar, Special, Design, Display } from '@guardian/libs';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think we need to think about these names here. i know they have big significance in editorial, but examples like this:

import { Special } from '@guardian/libs';
import { Design } from '@guardian/libs';

need to convey more to non-editorial devs i think. esp when it pops up in a list of possible imports in autocomplete (and in a generic org-wide library).

@JamieB-gu @oliverlloyd does something like this make sense?

import type { EditorialTheme, EditorialFormat } from '@guardian/libs';
import { EditorialPillar, EditorialSpecial, EditorialDesign, EditorialDisplay } from '@guardian/libs';

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point. Given that libs is dept-wide and not Editorial-specific the names do lose some context. Perhaps this is the best solution 🤔.

Although it's tricky because by making it more specific for non-consumers of these exports you're making it verbose/overly specific for the applications that do consume them. I don't have an idea for how to solve that though 😔.

Given that these may not live in this library for long do we want to do the large find-and-replace PRs on DCR, AR and IR to accommodate this change?

Apologies @sndrs none of what I've said is particularly conclusive, I've just added some more questions 🙈

cc @gtrufitt

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, import { Special } from '@guardian/libs'; lacks a lot of context outside of our bubble 🤔

EditorialSpecial is explicit but also a bit clunky. You'd probably end up import { EditorialSpecial as Special } from '@guardian/libs'; which I guess is fine but also a bit meh.

I'm guessing not but Is there an option to use a folder, like

import { Special } from '@guardian/libs/editorial';

?

Another option is to do what DCR does (in about 80% of places) and use the Type suffix, like

import { SpecialType, PillarType } from '@guardian/libs';

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the folder thing is an option but i'd rather avoid restructuring libs in order to accommodate importing ambiguous exports from types. e.g. we could potentially end up exporting two things with the same from different places which is even more ambiguity.

how do you feel about these instead?

import type { ArticleTheme, ArticleFormat } from '@guardian/libs';
import { ArticlePillar, ArticleSpecial, ArticleDesign, ArticleDisplay } from '@guardian/libs';

it has the advantage of not implying that only certain teams should them and ArticleDesign.MatchReport reads clearly to me?

another option: if this is still unacceptably verbose, perhaps that's a sign these things shouldn't live in here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd actually prefer EditorialDesign to ArticleDesign, because Article is a Design, so you'll end up with ArticleDesign.Article 🙈.

another option: if this is still unacceptably verbose, perhaps that's a sign these things shouldn't live in here?

That's reasonable. It's possible that they don't. They're specifically Editorial concepts and this is meant to be a dept-wide repo. They're only being put here for temporary convenience until we can get them into CAPI. Maybe instead we should just not deprecate @guardian/types until that migration to CAPI has finished?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah right that's interesting. so it sounds as though something like EditorialContentDesign.Article is probably an accurate, unambiguous name (or something like it), but the amount of context you need to pack in to that name perhaps means it's not generic enough to live in here (whereas living in CAPI provides that context implicitly)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, really, Article should be News or Standard

It probably should be Standard, you're right Oliver 🙄.

I don't think it should be News because a) it's not always used for news pieces, and b) News is a pillar 🙂.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify, is everyone happy for these values to change to

import type { ArticleTheme, ArticleFormat } from '@guardian/libs';
import { ArticlePillar, ArticleSpecial, ArticleDesign, ArticleDisplay } from '@guardian/libs';

and Design.Article to become ArticleDesign.Standard or do we close this PR and figure out a better place for Format to live?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy with ArticleTheme etc. 👍

Maybe the move from Article > Standard could be a separate PR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But also 👍 for Standard

```
17 changes: 17 additions & 0 deletions src/format.test.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
import { Design, Display, Pillar, Special } from './format';

it('Design enum contains Article', () => {
expect(Design.Article).toBeDefined();
});

it('Display enum contains Standard', () => {
expect(Display.Standard).toBeDefined();
});

it('Pillar enum contains News', () => {
expect(Pillar.News).toBe(0);
});

it('Special enum contains SpecialReport', () => {
expect(Special.SpecialReport).toBe(5);
});
Copy link
Contributor Author

@jamie-lynch jamie-lynch Jun 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This keeps coveralls happy but I'm not sure that it's much use beyond that. Interested to hear any thoughts on a better approach or whether it's just not worth it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, interesting that coveralls is really keen for you to run tests on what are essentially just type definitions - there's not really any logic to test there.

That said, testing the Theme enum might be useful, it's built as a compound of two other enums so I guess there's a chance for something to get broken there.

Otherwise, yeah I agree, this seems reasonable just to keep coveralls happy, but it's probably just running over ground that TSC covers anyway.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it seems Jest will always report enums as uncovered, unless maybe you use these enums somewhere?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're actually good tests to have. It's not unfeasible that someone might modify the type and accidentally modify an existing Type due to a typo, or change the ordering and have that somehow break something

54 changes: 54 additions & 0 deletions src/format.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
// ----- Types ----- //

enum Pillar {
News = 0,
Opinion = 1,
Sport = 2,
Culture = 3,
Lifestyle = 4,
}

enum Special {
SpecialReport = 5,
Labs = 6,
}

type Theme = Pillar | Special;

enum Design {
Article,
Media,
Review,
Analysis,
Comment,
Letter,
Feature,
LiveBlog,
DeadBlog,
Recipe,
MatchReport,
Interview,
Editorial,
Quiz,
Interactive,
PhotoEssay,
PrintShop,
JamieB-gu marked this conversation as resolved.
Show resolved Hide resolved
}

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

interface Format {
theme: Theme;
design: Design;
display: Display;
}

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

export type { Theme, Format };
export { Pillar, Special, Design, Display };
2 changes: 2 additions & 0 deletions src/index.ts
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,8 @@ export {
setCookie,
setSessionCookie,
} from './cookies';
export type { Theme, Format } from './format';
export { Pillar, Special, Design, Display } from './format';
export { getLocale } from './getLocale';
export { getSwitches } from './getSwitches';
export { isBoolean } from './isBoolean';
Expand Down