-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat: UI modifications to the article template #856
Conversation
This pull request has been linked to Shortcut Story #1115: UI modifications to the article template. |
// TODO: Find a way to destructure this. | ||
// I think I need to use nullish coalescing here, | ||
// but can't figure out how to write it properly | ||
// byline: { name: byline }, | ||
// location: { name: location }, |
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.
I made byline and location optional in the type, but can't figure out how to destructure them properly. I tried a few things: a ternary, default params, nullish coalescing, but none of that worked. Would love some input on this, but if we can't get it, then it works just fine declaring the old way as you can see below on lines 52, 55, 59 and 62.
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.
destructuring all the way would be nice, but I'm fine if we just keep it to the following and then byline.name
/ location.name
down in the code later. No need to get too complex with the destructuring, imo.
// TODO: Find a way to destructure this. | |
// I think I need to use nullish coalescing here, | |
// but can't figure out how to write it properly | |
// byline: { name: byline }, | |
// location: { name: location }, | |
byline, | |
location, |
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.
Guess the other option is to not make them optional, but that feels unnecessary since they are optional fields on article.
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.
Hurray we have content identifiers! Two things I noticed:
- It doesn't look like the category label is being displayed
- The order of the content identifiers should go from global to more granular (Category, Label, Tag) Right now it looks like it is going (Tag, Label)
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.
🎉
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.
Left a comment around the destructuring todo, but other than that looks good to me :)
{dateFormatter.format(publishedDateObj)} | ||
</time> | ||
</dd> | ||
<div> |
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.
thought: I was at first confused by the div
in the dl
but turns out it is valid html and there for grouping. https://www.stefanjudis.com/today-i-learned/divs-are-valid-elements-inside-of-a-definition-list/
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.
Thanks for mentioning this! I meant to add a comment about it, as I was initially having trouble grouping the dl
elements until I found the same docs.
// TODO: Find a way to destructure this. | ||
// I think I need to use nullish coalescing here, | ||
// but can't figure out how to write it properly | ||
// byline: { name: byline }, | ||
// location: { name: location }, |
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.
destructuring all the way would be nice, but I'm fine if we just keep it to the following and then byline.name
/ location.name
down in the code later. No need to get too complex with the destructuring, imo.
// TODO: Find a way to destructure this. | |
// I think I need to use nullish coalescing here, | |
// but can't figure out how to write it properly | |
// byline: { name: byline }, | |
// location: { name: location }, | |
byline, | |
location, |
// TODO: Find a way to destructure this. | ||
// I think I need to use nullish coalescing here, | ||
// but can't figure out how to write it properly | ||
// byline: { name: byline }, | ||
// location: { name: location }, |
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.
Guess the other option is to not make them optional, but that feels unnecessary since they are optional fields on article.
@@ -21,16 +27,58 @@ export const SingleArticle = ({ article }: { article: ArticleRecord }) => { | |||
|
|||
return ( | |||
<article className={styles.SingleArticle}> | |||
<div className={styles.title}> | |||
<div> |
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.
Q: Where do ORBIT Blog articles fit into this? Is that considered internal news? I know there are two separate categories in the CMS for internal news vs orbit blog, but don't see ORBIT Blog reflected in the constants in this repo. Did we miss something in the past, or am I getting the information architecture confused?
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.
Great question. I think we maybe missed this in the past? I think I added in the constants when creating the internal news page since we were trying to differentiate between what is public-facing and what isn't. But I don't believe the ORBIT Blog was available at that point? Since the blog is just updates that we are making, and the portal is open-source, it doesn't seem like it should be considered "internal." I guess this would ultimately be a design decision as to whether or not we need a new tag for this? Maybe we can discuss in our sync today.
## [4.12.0](4.10.0...4.12.0) (2022-12-13) ### Features * Add support for hero image in articles ([#862](#862)) ([56721db](56721db)) * add USSF Guardian Commitment Poster to docs page ([#888](#888)) ([07fb472](07fb472)) * Create USSF Documentation page ([#860](#860)) ([6c5d6b3](6c5d6b3)) * Display hero image in article layout ([#884](#884)) ([b2201ac](b2201ac)) * UI modifications to the article template ([#856](#856)) ([dc7402c](dc7402c)) ### Bug Fixes * **deps:** update dependency axios to v1 ([#851](#851)) ([de30320](de30320)) ### Security Improvements * **deps:** update node.js to v14.21.1 ([#849](#849)) ([46aba91](46aba91))
SC-1115
Proposed changes
A user will see the following new components on the article UI:
Reviewer notes
To see these changes in the UI:
Setup
As always, run both the portal client and the CMS on your local machine
Code review steps
As the original developer, I have
As code reviewer(s), I have
As a designer reviewer, I have
As a test user, I have
Screenshots