-
Notifications
You must be signed in to change notification settings - Fork 844
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
[EuiDescriptionList] Add new columnWidths
prop
#7146
[EuiDescriptionList] Add new columnWidths
prop
#7146
Conversation
8910b7c
to
15eecf6
Compare
Preview documentation changes for this PR: https://eui.elastic.co/pr_7146/ |
* _Advanced usage note:_ column width strings also accept [CSS grid special units, | ||
* sizing, keywords, and sizing functions](https://css-tricks.com/snippets/css/complete-guide-grid/#aa-special-units-functions). | ||
*/ | ||
columnWidths?: [number | string, number | 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.
Looking for feedback on whether folks think the [x, y]
array syntax is the most intuitive for devs, or whether we want to use object notation for more specific keys, e.g.
columnWidths={{
titles: '100px',
descriptions: '300px',
}}
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.
My 2¢ is the array is the more intuitive syntax. When I think of columns, I'm already thinking in an array-like structure. Being able to set an array and pass a string or number in two places, without having to know the correct key names, is huge. Admittedly this is less of an issue with TypeScript suggestions, but I still lean toward array.
That's an opinion loosely held, so I have no objection if there's a strong argument to move to an object.
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.
My 2¢ is the array is the more intuitive syntax. When I think of columns, I'm already thinking in an array-like structure.
I really like this reasoning - thanks Trevor! I will note one possible reason to use an object instead is if a consumer wants to specify the width of the title column but let the description column remain auto - an obj allows that, the array (currently) doesn't.
That being said, I don't see that as a use case right now, so let's move forward with the array syntax for now. We're looking to move fast due to this affecting the current Kibana upgrade, and if absolutely needed, we can come back in later and add other types with an |
.
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 an excellent plan!
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.
One copy suggestion and my 2¢ opinion on object vs. array for setting column widths. After that I'm ready to mark approved. Thanks for putting this together @cee-chen
src-docs/src/views/description_list/description_list_example.js
Outdated
Show resolved
Hide resolved
* _Advanced usage note:_ column width strings also accept [CSS grid special units, | ||
* sizing, keywords, and sizing functions](https://css-tricks.com/snippets/css/complete-guide-grid/#aa-special-units-functions). | ||
*/ | ||
columnWidths?: [number | string, number | 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.
My 2¢ is the array is the more intuitive syntax. When I think of columns, I'm already thinking in an array-like structure. Being able to set an array and pass a string or number in two places, without having to know the correct key names, is huge. Admittedly this is less of an issue with TypeScript suggestions, but I still lean toward array.
That's an opinion loosely held, so I have no objection if there's a strong argument to move to an object.
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.
💯 LGTM!
Preview documentation changes for this PR: https://eui.elastic.co/pr_7146/ |
💚 Build Succeeded
History
|
## PR change summary `v87.2.0`⏩`v88.1.0`⚠️ The biggest thing to QA in this PR is several **breaking changes** to `EuiDescriptionList`. ### Description list `columnWidths` prop This PR introduces a new `columnWidths` prop and removes several Kibana instances of custom CSS overrides to title/description column widths. The primary motivation behind this is not just to reduce custom CSS, but also because v88.0.0 introduced an underlying CSS change of `column` description lists to using [`display: grid` CSS](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout). The new prop allows us to support existing description list custom widths while not requiring Kibana developers to understand or write grid CSS (except for 1 or two scenarios around `max-width`).⚠️ **No user-facing UI around column widths should have regressed as a result of these changes. If they have, please let us know in this PR.** ### Description list gutter size changes The prop `gutterSize` has been renamed to `rowGutterSize` and the default size is now `s` instead of `m`. The change to `s` from `m` means there is an **expected** smaller gap between list items (see below screenshots): **Current `EuiDescriptionList` with default `rowGutterSize="s"`** <img width="753" alt="" src="https://github.com/elastic/kibana/assets/934879/c17aef28-ed3b-40c4-84c3-396e788b13bb"> **Prior `EuiDescriptionList` with default `gutterSize="m"`** <img width="721" alt="" src="https://github.com/elastic/kibana/assets/934879/84d5f5a2-8fa6-4f99-9dc0-73fd143aa1e1"> If Kibana teams prefer to keep the previous `m` gutter for their instances of `EuiDescriptionList`, you have a couple of options: 1. Let EUI team know in the PR and we can set usage back to what it was before 2. Set `rowGutterSize="m"` yourselves manually --- ## [`88.1.0`](https://github.com/elastic/eui/tree/v88.1.0) - Added `font.defaultUnits` theme token. EUI component font sizes default to `rem` units - this token allows consumers to configure this to `px` or `em` ([#7133](elastic/eui#7133)) - Updated `EuiDescriptionList` with new `columnWidths` prop ([#7146](elastic/eui#7146)) **Bug fixes** - Fixed `EuiDataGrid`'s keyboard shortcuts popover display ([#7146](elastic/eui#7146)) **CSS-in-JS conversions** - Renamed `useEuiFontSize()`'s `measurement` option to `unit` for clarity ([#7133](elastic/eui#7133)) ## [`88.0.0`](https://github.com/elastic/eui/tree/v88.0.0) - Updated `EuiDescriptionList` with a new `columnGutterSize` prop ([#7062](elastic/eui#7062)) **Deprecations** - Deprecated `EuiSuggest`. We recommend using `EuiSelectable` or `EuiComboBox` instead ([#7122](elastic/eui#7122)) - Deprecated `EuiControlBar`. We recommend using `EuiBottomBar` instead ([#7122](elastic/eui#7122)) - Deprecated `EuiColorStops`. We recommend copying the component to your application if necessary ([#7122](elastic/eui#7122)) - Deprecated `EuiNotificationEvent`. We recommend copying the component to your application if necessary ([#7122](elastic/eui#7122)) **Breaking changes** - Renamed `EuiDescriptionList`'s `gutterSize` prop to `rowGutterSize` ([#7062](elastic/eui#7062)) - `EuiDescriptionList`'s `rowGutterSize` prop now defaults to a size of `s` (was previously `m`) ([#7062](elastic/eui#7062)) **Accessibility** - Fixed the dark mode colors of inline `EuiDescriptionListTitle`s to meet WCAG color contrast requirements ([#7062](elastic/eui#7062)) **CSS-in-JS conversions** - Converted `EuiKeyPadMenuItem` to Emotion; Removed `$euiKeyPadMenuSize` and `$euiKeyPadMenuMarginSize` ([#7118](elastic/eui#7118)) --------- Co-authored-by: Cee Chen <[email protected]> Co-authored-by: Cee Chen <[email protected]> Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Nikita Indik <[email protected]>
Summary
This PR adds a new prop to
EuiDescriptionList
to smooth over changes made in #7062 (primarily the change that converted column data grids to usingdisplay: grid
).Unfortunately, many Kibana teams and EUI itself were setting custom column widths via CSS
flex-basis
orwidth
overrides, e.g.:eui/src/components/datagrid/controls/_data_grid_keyboard_shortcuts.scss
Lines 8 to 16 in a4493d9
The new
display: grid
CSS completely ignores both properties, resulting in broken looking UIs:This new prop adds a quick and easy way for consumers to customize column widths (clearly a frequently desired ability, considering there are 10+ CSS overrides in Kibana alone) without needing to know CSS grid to do so.
QA
General checklist
@default
if default values are missing)and playground togglesand cypress tests