-
Notifications
You must be signed in to change notification settings - Fork 64
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
Table
fixed layout
#2545
Table
fixed layout
#2545
Conversation
|
Size Change: +579 B (+0.04%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
) => | ||
cx(baseStyles, themeStyles[theme], bodyTypeScaleStyles[baseFontSize], { | ||
[css` | ||
//TODO: add to documentation |
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.
Will add in documentation PR
…fygreen-ui into shaneeza/table-fixed
…fygreen-ui into shaneeza/table-fixed
className={css` | ||
${index === 2 && | ||
css` | ||
width: auto; | ||
`} | ||
`} |
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.
can we add a comment here about why this is needed?
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.
In the Table/WithVirtualizedScrolling/DifferentHeights
example, this is a clip toggling between the 1440px and 1024px breakpoints
https://github.com/user-attachments/assets/5ce95740-7a77-449f-a344-52054244cdb0
This width: auto;
is causing the "Cluster Type" column width to shrink and because it's the most text-heavy data, it creates an appearance of a vertical gap in some rows
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 that this is just an unfortunate side effect of using table layout fixed with width auto. To avoid this, consumers will need to set a static width.
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 see, can we update this story to make it more like what might get used in prod for internal testing purposes? As is, I worry if it will be difficult to know in the future if this is a bug in the package vs in the story. Maybe a different column can be used to show responsiveness and we can add a min-width
, so it doesn't shrink to 0?
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.
@shaneeza tagging in case my reply got buried because I replied in thread rather than in a separate review
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.
Also, i forgot, It doesn't look like min-width works with a fixed layout
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.
gotcha, I still think it's strange that the column can shrink to 0 at smaller breakpoints, but good to go if that's expected / communicated that that can happen
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'll document it in my documentation PR
@@ -19,6 +19,8 @@ export const getBaseHeaderCellStyles = (size: number, isSelectable?: boolean) => | |||
&:first-of-type { | |||
${getCellPadding({ depth: 0, isExpandable: false, isSelectable })} | |||
} | |||
|
|||
line-height: 16px; |
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.
curious why this is added? also seeing an explicit height set in headerCellContentStyles
so wondering if only 1 is needed
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.
Rob asked me to add it - he felt the spacing could be tighter. I tried 1
, but it's tighter than 16px
. Also, we don't have any tokens that match this line-height.
✍️ Proposed changes
🎟 Jira ticket: Name of ticket
✅ Checklist
For bug fixes, new features & breaking changes
yarn changeset
and documented my changesFor new components
🧪 How to test changes
Click on the
Different Heights
story underTable/With Virtualized Scrolling
. Open the story outside of an iframe and start scrolling.