-
Notifications
You must be signed in to change notification settings - Fork 69
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
Discussions Card Component Design Only #2339
Conversation
@HS-90 is attempting to deploy a commit to the c0d3-prod Team on Vercel. A member of the Team first needs to authorize it. |
Codecov Report
@@ Coverage Diff @@
## master #2339 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 181 182 +1
Lines 3187 3192 +5
Branches 843 845 +2
=========================================
+ Hits 3187 3192 +5
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
<span> - </span> | ||
<span>{timeStamp}</span> | ||
</div> | ||
<div className={styles.expand_button} onClick={expandClick()}> |
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 think you meant to put onClick={expandClick}
instead.
</div> | ||
</div> | ||
<div className={styles.likes_container}> | ||
<div className={styles.likes_button} onClick={likeClick()}> |
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.
Change to onClick={likeClick}
.
<ThumbsupIcon className={styles.thumbs_up_down} />{' '} | ||
<span className={styles.number_shown}>{likes}</span> | ||
</div> | ||
<div className={styles.likes_button} onClick={dislikeClick()}> |
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.
Change to onClick={dislikeClick}
.
} from '@primer/octicons-react' | ||
|
||
export type DiscussionsCardProps = { | ||
discussionType: 'main' | string |
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.
You can change this to type 'main' | 'sub'
if that makes more sense.
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.
@HS-90 Is there any potential that there will be more than 2 possible values for discussionType
? Also, what is the reason for different styling options? Do we have different styling on different pages for DiscussionCard component?
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'm thinking that if we know there will never be more than 2 possible values for discussionType
, then we might as well simplify things make the prop a boolean value, ex. subMode?: boolean
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.
If theres high potential that discussionType will have more than 2 possible values, id suggest we use a mapping approach instead of using ternary operators(see lines 39 and 42 for example)
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.
Example of mapping approach:
className={styles[`card_body_${discussionType}]}
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.
The above might be a bad example.. im not sure its a good idea for name of theclass
to be part of the logic in this kind of way because it makes the logic more complex
A more simple approach would probably be to have main
and sub
as keys in a hashmap, and then have as its values the corresponding styles for them
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.
If theres high potential that discussionType will have more than 2 possible values, id suggest we use a mapping approach instead of using ternary operators(see lines 39 and 42 for example)
There should be only 2 types if we are going by design, one is a main card, which will be the original comment or thread, then replies will be the sub design, branching off of the original comment.
A subcard can also have subcards branching off of them, kind of like how reddit works. but the design should be the same for every subcard, if that makes sense. I think I agree with your boolean approach.
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.
If the only purpose of having a boolean is to check if a reply is the main one, wouldn't be better to instead check if the subreply doesn't have any parent comment and style accordingly?
Also, should we consider that any subreply that has n replies would be considered a main? if so, wouldn't that make things a bit confusing?
We didn't get to this point in the design meetings.
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.
If the only purpose of having a boolean is to check if a reply is the main one, wouldn't be better to instead check if the subreply doesn't have any parent comment and style accordingly?
Why is it better?
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.
After a bit of though, it seems like it won't make any difference in our case, the only case it would be useful is if we want to style subthread replies with different levels/shades of colors.
<span>{timeStamp}</span> | ||
</div> | ||
<div className={styles.expand_button} onClick={expandClick()}> | ||
... |
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.
What does the expandClick function do in this case? I remember from the design sessions the idea behind was to use it to edit/delete the comment, but it looks like those two have their own button in this design, should we keep it?
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.
It depends. Do we want to show every response to the thread(including responses to responses) upon load, or do we want the user to click first before it expands?
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.
Interesting, i didn't think it would be used for collapsing comments.
I don't think hiding the thread upon load is a good idea, threads should all be visible and if the thread is too long, we can add a button to show more responses.
Maybe we can make the comments with a negative score collapsed by default? That would be a good use for it. Do we have a design on the collapsed state?
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.
Do we have a design on the collapsed state?
Only the discussion cards so far. Haven't implemented the full UI yet. I agree that we can load them all to a certain point.
Should we have all responses feed to main parent post(the purple design), even if they were responding to a sub post? Or should we have it like reddit, where it continues branching out if you reply to a sub post?
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.
Should we have all responses feed to main parent post(the purple design), even if they were responding to a sub post? Or should we have it like reddit, where it continues branching out if you reply to a sub post?
I think having something similar to reddit is the way to go, we just need to make sure that the design will not break once we have too many branches.
</div> | ||
<div className={styles.likes_container}> | ||
<div className={styles.likes_button} onClick={likeClick()}> | ||
<ThumbsupIcon className={styles.thumbs_up_down} />{' '} |
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.
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.
@flacial Can you confirm which one did we agree on?
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 think without likes. On v2 of the discussions component, we can implement likes then.
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 think without likes. On v2 of the discussions component, we can implement likes then.
Should we not include likes in the current PR? And add the up down arrows in a future PR?
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.
Or are you talking about V2 as in, after this initial discussions component has been fully implemented without likes.
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.
Or are you talking about V2 as in, after this initial discussions component has been fully implemented without likes.
Yes, after this initial design.
… removed css for deleted parts, updated DiscussionCardProps
Updated screenshots of designs: Link to storybook: https://deploy-preview-2339--youthful-thompson-448332.netlify.app/?path=/story/components-discussionscard--discussions-card-main If everyone is ok with the initial designs of these cards, we can merge and then update functionality in future PRs. |
The image used for This isn't a blocker though, we can always update this later since this PR only adds the component. I just wanted to point this out |
I good with switching the icon. Is that also a react icon? Or a different library? |
Im not sure about where to find an icon like reddit's to use. |
@HS-90 Yeah, a similar icon is available in Octicons: https://primer.style/octicons/comment-16 |
What it looks like with comment icon. |
Looks good! One small detail, i think 10px is too much for the border radius on the hover state, 5px would look a lot better! |
Description: relates to #2252
This PR creates the initial design for the two different types of discussion cards as shown in this design:
https://www.figma.com/file/f9xRyl1bJOjtBRd8zFORzg/c0d3
The submitted PR is not designed 1 to 1 compared to figma, but we can discuss and come up with a finalized design if necessary.
You can view this design by running
yarn storybook
and viewDiscussionsCard
. Additionally, here are screenshots of the design below:Main Card:
Sub Card: