Skip to content
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

[EuiDataGrid] Add rowHeightSwitcher logic + API change #5372

Conversation

cee-chen
Copy link
Member

@cee-chen cee-chen commented Nov 10, 2021

Summary

This is a fairly hefty PR and I strongly recommend following along by commit.

TL;DR:

  • Deprecated showStyleSelector in favor of showDisplaySelector
  • New showDisplaySelector nested config options: { allowDensity: true, allowRowHeight: true }
  • Fixed undefined/"Single" row heights to correctly account for density by changing them to also use this.props.setRowHeight to dynamically adjust their minRowHeight (basically re-using the same logic as lineCount row heights)

Screencaps

screencap

lineCount

Code coverage

Checklist

  • Check against all themes for compatibility in both light and dark modes
  • Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
  • Props have proper autodocs and playground toggles
  • Added documentation

- [ ] Checked Code Sandbox works for any docs examples

NOTE: Cypress testing will likely need #5371 for styles - leaving this as a tech debt/backlog item

  • Checked for breaking changes and labeled appropriately
  • Checked for accessibility including keyboard-only and screenreader modes
  • A changelog entry exists and is marked appropriately

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

cee-chen and others added 7 commits November 11, 2021 11:54
- so that both the columnSelector and displaySelector can use it
+ update docs:
  - reorder UI to match toolbar layout
  - fix legends

+ add unit tests (& improve some existing unit tests)
NYI: conditional lineCount controls

+ unit tests
+ fix cell height to dynamically on lineCount change
…efined heights but defined rowHeightsOptions objects

e.g. - empty objs, or lineHeight set but nothing else

+ simplify this.props
…ined mode

- Multiline content includes items with `<br>`/`<p>` tags etc that end up incorrectly vertically centered to their increased height
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

… + density

- by giving it the same setRowHeight logic as line counts with a single line

+ rename recalculateLineCountHeight for clarity now that it's no longer being used for just lineCount
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@cee-chen cee-chen marked this pull request as ready for review November 11, 2021 23:24
@@ -139,7 +140,7 @@
.euiDataGridRowCell__expandFlex {
position: relative; // for positioning expand button
display: flex;
align-items: center;
align-items: baseline;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without this fix (be59b08), cell contents that are multiline due to <br>s/<p>s/other non-text-wrapping means would not correctly be aligned on 'Single'/undefined row heights:

Before (center-aligned)

After (top/base-aligned)

Note that this actually already an issue on production, this PR simply makes it more obvious because the row height switcher easily allows users to switch to single/undefined row heights on multi-line content, whereas previously a consumer would likely set a static row height or lineCount.

Also ignore the incorrect line height in this screenshot, this is an issue that gets fixed in the next commit.

Comment on lines +196 to +199
const isSingleLine = rowHeightOption == null; // Undefined rowHeightsOptions default to a single line
const lineCount = isSingleLine
? 1
: rowHeightUtils?.getLineCount(rowHeightOption);
Copy link
Member Author

@cee-chen cee-chen Nov 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fix/workaround essentially has the single/undefined row heights act as lineCount of 1, which allows single rows to take advantage of lineCount's ability to get cell heights/font sizes/line heights and dynamically respond to density changes.

Before:

The non-dynamic height changing is even more noticeable now that single row heights are no longer center aligned (per previous commit/fix) and now that you can compare lineCount directly against undefined, which does correctly reset the minimum row height based on density.

before

After:

after

I initially played with an approach that used a static minRowHeight map depending on density and exporting that from the display selector - but I think this approach is much simpler/better because it's using the logic we already have, and also accounts for row/line height differences between the legacy theme and Amsterdam theme.

This also fixes an issue that occurs when switching from lineCount to undefined heights - the undefined heights' minRowHeight was not being correctly reset, so this approach basically kills two birds with one stone.

- to make the difference more obvious when switching between single and custom
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@cee-chen
Copy link
Member Author

jenkins test this

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@cchaos
Copy link
Contributor

cchaos commented Nov 17, 2021

So I'm noticing a bit of a discrepancy between how the "Single" and "Auto fit" behave when there is only a single line of content. I'd expect the heights of the cells to continue to be the same. Also in compressed style, I think the height is too high when "Auto fit".

Screen.Recording.2021-11-17.at.12.13.18.PM.mp4

EDIT: It looks like this stems from the "Single" version version not taking the actions column into account so the button is getting cutoff.
Screen Shot 2021-11-17 at 12 18 34 PM

@cee-chen
Copy link
Member Author

cee-chen commented Nov 17, 2021

Just to clarify, "Single" heights have never taken the actions column into account, what they did was just vertically center all of their content which was fine for things like buttons or text that never had manual <br /> type breaks in them. The problem was also not as noticeable on compressed densities because we previously enforced a minimum height of 34px on single heights.

I think the solution here is to tweak control columns buttons by reducing their size or padding/margins on compressed density (so it's not causing the height to be too tall on auto, and so it's correctly aligned on single/lineCount mode).

EDIT: Actually on second thought https://eui.elastic.co/pr_5372/#/tabular-content/data-grid-control-columns/ is fairly derpy as well (primarily checkboxes) even on normal density so I think the perhaps more robust solution is to switch control columns only back to a center vertical alignment (since theoretically those columns should not contain multi-line text).

EDIT 2: Actually both is required. Fun times!

@chandlerprall
Copy link
Contributor

Then when the user selects an option, change it for all the rows even the very specifically set by index ones.

I'm hesitant to agree with this premise. I somewhat deliberately left the rowHeights overrides untouched by the new row height UI, which only sets the defaultHeight of the grid. I didn't see this as functionality that was requested or needed by the Discover team in #5080 (although we can certainly ask!). I think my hesitation here is that rowHeights is clearly billed as an override, and it feels strange to have an override that's so easily overrideable by the user. It's certainly technically doable, I just want to make sure it's a deliberate choice we're making (and also that we document it super clearly).

This is tricky, and I flopped back and forth a bit in that section during my review. Looking ahead to the ask for row renderers, I can see a world where there are "rows" and ... "extra rows" (conceptually in the application, not within EUI code), with the extra rows getting an auto height while the rows use the default set by either application or user. Based on this, I lean toward the existing implementation where the override affects only the default. In theory, there's a really good reason for the application to set a specific height on something.

I also appreciate the scenario where a user is confused when only a subset of rows are affected by their choice.

@cee-chen
Copy link
Member Author

cee-chen commented Nov 23, 2021

If a consumer has deliberately chose specific heights for specific rows, my guess is they don't want the consumer to adjust the row heights at all.

Those are good points! Could we configure the specific rows example to turn off showDisplaySelector.allowRowHeight, and add a documentation note that we recommend disabling that configuration if setting individual row height overrides?

Is that a slightly happier medium between programmatically enforcing/disabling the row height switcher whenever a rowHeights object override is set?

@cchaos
Copy link
Contributor

cchaos commented Nov 23, 2021

So something like?:

rowHeightsOptions = {
  defaultHeight: 140, // Row heights selector still shows but unselected
  rowHeights: {
    1: {
      lineCount: 5,
      allowRowHeight: false, // Ensures it doesn't change based on row height selector
    },
    4: 200, // Will adjust based on row height selector, this is just the starting height
  },
}

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@cee-chen
Copy link
Member Author

Not quite sorry, I just meant changing the actual src-docs/../row_height_fixed.tsx example itself to disable toolbar config:

<EuiDataGrid
  // ...
  toolbarVisibility={{
    showDisplaySelector: { allowRowHeight: false },
  }}
  rowHeightsOptions={rowHeightsOptions} // has rowHeights overrides
/>

@cchaos
Copy link
Contributor

cchaos commented Nov 23, 2021

Ok, as a compromise, add that to the docs example with a note in the description (and the props comment for rowHeightsOptions) that we recommend also turning off allowRowHeight. Then let's make an issue to specifically address this as a follow up. I think I still like my suggestion where we enforce a good UX but consumers can opt-out. The issue doesn't have to be addressed in this feature branch either.

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll apply my pre-approval now in case the rest of them come in while I'm out. 😅 Awesome job!! I think the final UI is intuitive and I'm glad we, but mostly you, took the time to work through all the rest of the toolbar stuff to go with it.

+ improve unit tests to cover undefined nested object key case
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@cee-chen
Copy link
Member Author

rowHeights documentation and issue:

Copy link
Contributor

@chandlerprall chandlerprall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Read through & tested the updated examples, looks like all review feedback has been addressed.

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@chandlerprall
Copy link
Contributor

Interesting Cypress failure, gonna see if a re-run passes; jenkins test this

10:43:44 EuiDataGrid
10:43:44 row creation
10:43:44 (Attempt 1 of 3) creates rows
10:43:45 1) "after all" hook: mergeUnitTestCoverage for "creates rows"
10:44:09
10:44:09
10:44:09 0 passing (25s)
10:44:09 1 failing
10:44:09
10:44:09 1) EuiDataGrid
10:44:09 row creation
10:44:09 "after all" hook: mergeUnitTestCoverage for "creates rows":
10:44:09 Error: The following error originated from your test code, not from Cypress.
10:44:09
10:44:09 > ResizeObserver loop limit exceeded

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

@cee-chen
Copy link
Member Author

It's failed a couple times now on this branch since latest main was merged in, so unfortunately I think it might be a persistent failure. I can repro it locally as well. An easy fix would just be to ignore the specific ResizeObserver loop limit error, but I'm a little worried it's somehow related to changes in this branch (although I can't really see how it would specifically affect E2E tests)

@cee-chen
Copy link
Member Author

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5372/

Copy link
Contributor

@chandlerprall chandlerprall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙌 thanks for tracking down all that info

@cee-chen cee-chen merged commit ff742c6 into elastic:feat/datagrid/toolbar-reorg-and-row-height-switcher Nov 24, 2021
@cee-chen cee-chen deleted the datagrid-row-height-control branch November 24, 2021 21:01
cee-chen pushed a commit that referenced this pull request Dec 7, 2021
…5415)

* [EuiDataGrid] Toolbar UI layout reorganization (#5334)

* [EuiDataGrid] Add extra left prepend position to the `additionalControls` API (#5394)

* [EuiDataGrid] Add rowHeightSwitcher logic + API change (#5372)

* [EuiDataGrid] Add `onChange` callbacks for display selector changes (#5424)

* [EuiDataGrid] Row height switcher should override `rowHeights` + add reset button (#5428)

* [EuiDataGrid] improve height calculation (#5447)

Co-authored-by: Caroline Horn <549577+cchaos@users.noreply.github.com>
Co-authored-by: Chandler Prall <chandler.prall@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants