-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move ArticleFormat
Parsing Into DCAR
#10543
Conversation
Size Change: 0 B Total Size: 767 kB ℹ️ View Unchanged
|
Hello 👋! When you're ready to run Chromatic, please apply the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes!
This makes me wonder why the article types live in @guardian/libs
For now because |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
❤️ |
Moves as much of the parsing of `ArticleFormat` as possible into DCAR, so we no longer have to rely on the CAPI client to do this. The current logic duplicates exactly what the CAPI client does, so that we don't change too much at once. Improvements to the parsing logic can be made in a future change, once we've confirmed everything works as before. At the moment, there isn't enough of the CAPI data available from frontend to fully parse `ArticleFormat`. Three further pieces of information are needed: 1. Content type (`content.type` in CAPI) 2. Display hint (`content.fields.displayHint` in CAPI) 3. Whether a blog is currently live (`content.fields.liveBloggingNow` in CAPI) In cases where these items are missing, the parsing logic falls back to the frontend definition of `ArticleFormat`. Once they are made available, in a future change, these fallbacks can be removed. This change also renames `format.ts` to `articleFormat.ts`, to more closely resemble the name of the type.
fcdbf24
to
54f4ae3
Compare
"This PR is stale because it has been open 30 days with no activity. Unless a comment is added or the “stale” label removed, this will be closed in 3 days" |
This PR was closed because it has been stalled for 3 days with no activity. |
Moves as much of the parsing of
ArticleFormat
as possible into DCAR, so we no longer have to rely on the CAPI client1 to do this. The current logic duplicates exactly what the CAPI client does2, so that we don't change too much at once. Improvements to the parsing logic can be made in a future change, once we've confirmed everything works as before.At the moment, there isn't enough of the CAPI data available from frontend3 to fully parse
ArticleFormat
. Three further pieces of information are needed:content.type
in CAPI)content.fields.displayHint
in CAPI)content.fields.liveBloggingNow
in CAPI)In cases where these items are missing, the parsing logic falls back to the frontend definition of
ArticleFormat
. Once they are made available, in a future change, these fallbacks can be removed.This change also renames
format.ts
toarticleFormat.ts
, to more closely resemble the name of the type.Footnotes
https://github.com/guardian/content-api-scala-client ↩
https://github.com/guardian/content-api-scala-client/blob/ea995d3282281029b9eaedd1e3566aebe6ac7300/client/src/main/scala/com.gu.contentapi.client/utils/CapiModelEnrichment.scala#L94 ↩
https://github.com/guardian/dotcom-rendering/blob/89b180e31d73cc11d31e7562624bd46364e28f7b/dotcom-rendering/src/types/frontend.ts#L20 ↩