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

Hide paginationBar in EuiBasicTable when there is no data #2598

Merged
merged 13 commits into from
Dec 9, 2019

Conversation

andreadelrio
Copy link
Contributor

@andreadelrio andreadelrio commented Dec 6, 2019

Summary

This PR introduces two changes in EuiBasicTable:

  1. Hides pagination when there are no rows.
  2. Hides pagination if the number of rows is less than the minimum passed in pageSizeOptions. For example:

pageSizeOptions = [3, 5, 8]
totalItemCount > 3 -> Display pagination? Yes
totalItemCount <= 3 -> Display pagination? No

Fixes #899

Checklist

- [ ] Checked in dark mode
- [ ] Checked in mobile
- [ ] Checked in IE11 and Firefox
- [ ] Props have proper autodocs
- [ ] Added documentation examples

  • Added or updated jest tests
    - [ ] Checked for breaking changes and labeled appropriately
    - [ ] Checked for accessibility including keyboard-only and screenreader modes
  • A changelog entry exists and is marked appropriately

@chandlerprall
Copy link
Contributor

chandlerprall commented Dec 6, 2019

Let's hold off on merging this until #2428 (tables conversion to typescript) is in. This should be able to drop into the new pagination_bar.tsx file without issues, but would like to avoid any potential merge conflicts especially as the TypeScript PR is a community contribution.

edit: Note: git understood the conversion of pagination_bar.js -> pagination_bar.tsx as a rename of the file, so I would expect a rebase or merge of master for this PR to automatically adjust to the changes without a conflict.

@chandlerprall
Copy link
Contributor

chandlerprall commented Dec 6, 2019

I wonder about the efficacy of this decision. I can envision scenarios where a hidden pagination bar would confuse a user who believes there is more data and that a bug is preventing access, rather than communicating that there is only one table worth of data.

If we do decide this is the right thing to do, I would question if this logic should be in the pagination bar or in any consuming locations (i.e. check the row count against the minimum page size in the table code instead of the pagination bar), as that allows the pagination bar to be used/displayed in any situation where we (or a consuming dev) wants to show a pagination bar with only one page.

@cchaos thoughts? Mostly I want to make sure these questions were/are thought about - I'm fine being wrong as long as the discussion happen(s/ed)!

@andreadelrio
Copy link
Contributor Author

I wonder about the efficacy of this decision. I can envision scenarios where a hidden pagination bar would confuse a user who believes there is more data and that a bug is preventing access, rather than communicating that there is only one table worth of data.

@chandlerprall You bring up a valid point. I spent yesterday going back and forth between hiding the pagination or not in this scenario and see arguments for either direction. However, I just checked a reference that I like (Mint) and they keep the "rows per page" UI element even when there's no enough rows of data. See:

Screen Shot 2019-12-06 at 8 14 16 AM

In what cases does the number of rows change? I can think of a) search b) filters, and in this new implementation we would be hiding the pagination which as you said could be confusing.
The one solution I can think of for that would be for the consumer to display something like "Displaying 5 results" (like Mint does) but I understand we want our component to be as intuitive as possible out of the box.

@cchaos
Copy link
Contributor

cchaos commented Dec 6, 2019

@andreadelrio It would also be helpful to evaluate this decision with screenshots. Otherwise I have to manipulate the example codes in order to view the scenarios.

I am also confused when we talk about pagination vs rows per page. I feel these are either two separate UI's or Pagination encompasses the actual EuiPagination component and the rows per page. Can you clarify those distinctions?

Thinking about it generally, I would assume:

  1. Empty table: (Meaning, it's empty to start, the user has no data at all.) The table itself (should) show a message that it is empty and therefore I agree that the entire Pagination should not be present.
  2. Any data: (Meaning, even if it's just 1 row or searching came up with no results.) Only the EuiPagination should hide but the rows per page should still be visible.

In any case, we will also eventually need some sort of caption explaining how many total results #1237.

@andreadelrio
Copy link
Contributor Author

@andreadelrio It would also be helpful to evaluate this decision with screenshots. Otherwise I have to manipulate the example codes in order to view the scenarios.

I am also confused when we talk about pagination vs rows per page. I feel these are either two separate UI's or Pagination encompasses the actual EuiPagination component and the rows per page. Can you clarify those distinctions?

Thinking about it generally, I would assume:

  1. Empty table: (Meaning, it's empty to start, the user has no data at all.) The table itself (should) show a message that it is empty and therefore I agree that the entire Pagination should not be present.
  2. Any data: (Meaning, even if it's just 1 row or searching came up with no results.) Only the EuiPagination should hide but the rows per page should still be visible.

In any case, we will also eventually need some sort of caption explaining how many total results #1237.

@cchaos So far I’ve been using "Pagination" to refer to PaginationBar which includes two elements: itemsPerPagePopover and EuiPagination. I think this that you pointed out (that we are dealing with two different elements) makes it more clear for me which way we should go. I say we stay with the current way we handle PaginationBar whenever there's any data (i.e. hide EuiPagination but keep showing itemsPerPagePopover). @chandlerprall what do you think?

To make sure we're all on the same page, this would look like this (again, this is what we were already doing)

aaaaa_Artboard

Screen Shot 2019-12-06 at 9 23 30 AM

@chandlerprall
Copy link
Contributor

For user experience, I would prefer showing e.g. Page 1 of 1 instead of disappearing EuiPagination altogether.

@thompsongl
Copy link
Contributor

Screenshots are helpful. Thanks!

I think that the itemsPerPagePopover text gives enough indication that there is no more data to be loaded, except in cases where the number of available rows equals the set number of rows per page. Adding 'Page 1 of 1' in place of EuiPagination as Chandler suggested seems like a good move for clarity.

@andreadelrio
Copy link
Contributor Author

I think that the itemsPerPagePopover text gives enough indication that there is no more data to be loaded, except in cases where the number of available rows equals the set number of rows per page. Adding 'Page 1 of 1' in place of EuiPagination as Chandler suggested seems like a good move for clarity.

I think that itemsPerPagePopover is enough even when the number of available rows equals the chosen "rows per page" number. When seeing this, I would expect users to know that there's only one page.
image

Also, the caption that we will eventually add (#1237) could help make things even more clear for this particular case (# rows = chosen # of rows per page).

@cchaos
Copy link
Contributor

cchaos commented Dec 6, 2019

@chandlerprall It sounds like you just don't agree with this ticket #899 to begin with?

The only problem with Page 1 of 1 is that's not what our pagination currently says, if that's explicitly what you want it to say.


I think that itemsPerPagePopover is enough even when the number of available rows equals the chosen "rows per page" number.

I actually think that is more confusing. The number of rows selector should not change (just like in your Mint example). It would be more indicative if you have only 3 rows and the selector says "10 rows per page" that you only have 3 results. Otherwise, I could possibly think there are more pages of 3 rows since I'm only seeing that same amount.

70347577-b0559500-1815-11ea-8a74-beaa9c370b07


I think we've beaten this over the head too much. I would say that we should:

  1. Only remove the pagination items if there is 0 data. (Not 0 search results)
  2. Leave the rows per page number the same no matter how many results are available
  3. Leave the page numbers even if there's only one page

@andreadelrio andreadelrio changed the title Display pagination in EuiBasicTable only when needed Display paginationBar in EuiBasicTable only when needed Dec 6, 2019
@andreadelrio andreadelrio changed the title Display paginationBar in EuiBasicTable only when needed Hide paginationBar in EuiBasicTable when there is no data Dec 6, 2019
@andreadelrio
Copy link
Contributor Author

Going with Caroline's suggestions as I think they're a happy medium. Looks like this when there's only one page.

image

@andreadelrio
Copy link
Contributor Author

I think that itemsPerPagePopover is enough even when the number of available rows equals the chosen "rows per page" number.

I actually think that is more confusing. The number of rows selector should not change (just like in your Mint example). It would be more indicative if you have only 3 rows and the selector says "10 rows per page" that you only have 3 results. Otherwise, I could possibly think there are more pages of 3 rows since I'm only seeing that same amount.

70347577-b0559500-1815-11ea-8a74-beaa9c370b07

I think there might have been a misunderstanding, I wasn't suggesting the number of rows selector should change. I agree with the behaviour you're describing.

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 deleted my previous comment since I was a dummy and was looking at the published site.
The only scenario that still seems to be off is when searching in EuiMemoryTable and there are 0 results, I'd think we'd still want the whole pagination bar. But the empty message helps to convey that there aren't any results so is it necessary?

image

Other than that, just had some code cleanup comments.

CHANGELOG.md Outdated
Comment on lines 6 to 7
- Hide `paginationBar` in `EuiBasicTable` when there is no data ([#2598](https://github.com/elastic/eui/pull/#2598))
- Display `EuiPagination` in `EuiBasicTable` when there is only 1 page ([#2598](https://github.com/elastic/eui/pull/#2598))
Copy link
Contributor

Choose a reason for hiding this comment

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

These entries can be rolled into one because they both are affecting EuiBasicTable pagination options

@@ -384,7 +384,7 @@ export class EuiBasicTable extends Component {
);

const table = this.renderTable();
const paginationBar = this.renderPaginationBar();
const paginationBar = this.renderPaginationBar(items);
Copy link
Contributor

Choose a reason for hiding this comment

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

A better thing to pass here would be the length of items so that there's an understanding of what the renderPaginationBar() method is doing with that parameter which is just checking that items to do exist.

Suggested change
const paginationBar = this.renderPaginationBar(items);
const paginationBar = this.renderPaginationBar(items.length);

@@ -1049,9 +1049,9 @@ export class EuiBasicTable extends Component {
return profile.align;
}

renderPaginationBar() {
renderPaginationBar(items) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Then here, you can change the name to something like

Suggested change
renderPaginationBar(items) {
renderPaginationBar(numItems) {

@@ -173,7 +173,7 @@ export const EuiPagination: FunctionComponent<Props> = ({
</EuiI18n>
);

if (pages.length > 1) {
if (pages.length > 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

pages.length will never be less than 0 so this statement will always return true, which means that it's an unnecessary check the component should always return the full pagination and never an empty span.

@andreadelrio
Copy link
Contributor Author

andreadelrio commented Dec 9, 2019

I deleted my previous comment since I was a dummy and was looking at the published site.
The only scenario that still seems to be off is when searching in EuiMemoryTable and there are 0 results, I'd think we'd still want the whole pagination bar. But the empty message helps to convey that there aren't any results so is it necessary?

image

I had missed the bit where you said "Not 0 search results" here => 1. Only remove the pagination items if there is 0 data. (Not 0 search results) I particularly think the message should be plenty to prevent the user from having any confusion with PaginationBar not showing up.

If we were to show PaginationBar when there are 0 search results it would look something like this:
image
I'm almost thinking that the user could find this buggy/weird. I associate "page number" with "there's some data" (regardless of if that data is "search results" or not).

@chandlerprall
Copy link
Contributor

I'm happy with the direction this is going. I'll remove myself from the rest of the conversation, but do a final technical pass when the functionality is stable.

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'm good with that decision (leaving pagination off if 0 results). LGTM!

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.

Changes LGTM; pulled & tested locally

Need to update &commit jest's snapshots for this to pass CI - yarn test-unit -u

@andreadelrio
Copy link
Contributor Author

jenkins test this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

When table is empty, don't show rows per page UI
4 participants