-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
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
refactor(theme-classic): clean up CSS of doc cards #6950
Conversation
And if I understand correctly, doc cards can not be without a link? So is that why this code can be removed also?
|
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site settings. |
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-6950--docusaurus-2.netlify.app/ |
Size Change: -265 B (0%) Total Size: 805 kB
ℹ️ View Unchanged
|
It could actually happen, when The only case in reality that I can think of right now is when a category contains only pure HTML items. |
How about hiding such categories without a link? Why would they show them in that case? |
Yeah, it makes sense to hide them IMO🤷♂️Can't think of any other cases where a card doesn't have an href. |
I like the border color change! However, I also find some value in the card slightly illuminating in dark mode... |
Alright, replaced with |
Uh, miswording there. I meant that the background should probably be lightened a little bit like before when hovering, in addition to the highlighted border. But the current one looks fine as well. |
Background then needs to be changed on hover state for all color modes, but currently it is required only for dark one. However, this breaks the design consistency, so I decided to highlight border instead for all modes. |
I think in light mode it thickens the box shadow instead. Since box shadow is usually substituted with lighter foreground in dark mode to signal elevation. |
Yes, so border seems like a reasonable alternative to background in that case. |
Yeah, still looks good to me. It might also be good for accessibility since the contrast seems more significant |
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 👍
Requesting some minor changes
Done, I also made a few minor semantic improvements. |
@@ -81,7 +81,7 @@ function CardCategory({item}: {item: PropSidebarItemCategory}): JSX.Element { | |||
{count: item.items.length}, | |||
)} | |||
/> | |||
); | |||
) : null; |
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.
same as before, I'd like any comp in DocCard to never render null as it's the responsibility of the list to filter or not items upfront
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.
That's because the findFirstCategoryLink
function can return undefined
. But since we have a validation rule that prevents empty items in categories, we can assume that there will always be a link.
@@ -15,11 +15,20 @@ export default function DocCardList({ | |||
}: { | |||
items: PropSidebarItem[]; | |||
}): JSX.Element { | |||
const filteredItems = items.filter((item) => { |
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.
not sure this test is so great as it potentially not filter categories that have no link
the rule for filtering (not rendering) an item should be clear and in a single place (here)
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.
Don't really understand, can you give concrete use case for testing?
Understand better now, did some minor edits to make things clearer 👍 LGTM |
function filterItems(items: PropSidebarItem[]): PropSidebarItem[] { | ||
return items.filter((item) => { | ||
if (item.type === 'category') { | ||
return !!findFirstCategoryLink(item); |
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.
That seems more expensive than before because we traverse the entire subtree twice. Is it worthwhile?
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.
Oh, otherwise we render an empty article
container😅 Well, fair then. A little nasty
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.
That seems more expensive than before
Agree but at the same time it's unlikely that the user build complex sidebar trees without any link, in most cases the link is found fast
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.
Yeah, makes sense 👍
The web is down these days, CI just doesn't kick😕 |
Motivation
Removing unnecessary CSS code and trying to use
transform
for hover state, because changingbackground
only in dark mode breaks the consistency of the current visual design.Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Preview.
Related PRs