Paging in a Table Card

Hi there,

I was reading a closed forum question that suggested an answer that may no longer be true at this date. Original Question:

I have a Mega Table with about 600 rows. I don't want to show all 600 at the Dashboard level, even with the scrolling aspect. I'm concerned that it will affect the Dashboard Performance. The row limit feature doesn't solve my issue because the dynamic sorting isn't as friendly when there is a row limit. The table only shows the top 10 based on the designated card sort, but doesn't show the top 10 from the Dashboard level if a user sorts on a different column.

The only card that I can see that has a paging option is the Checkbox Selector Filter Card.

What suggestions do you all have on the best way to chart this data? Below is a snapshot of what I currently have. You can see how small the scroll bar is, so the list goes pretty long.

Thank you in advance!

Tagged:

Best Answers

  • ColemenWilson
    edited September 2023 Answer ✓

    Is page performance your only concern? If so, have you tested the performance with all 600 rows? We have pages with table cards with that many rows and performance doesn't seem to be an issue at all. If you really don't want to have the 600 row table card on the page, you could change the interaction of the card at the dashboard level so that clicking it takes the user to a different card (the one with all 600 rows) but at the dashboard level it could be a separate card that has limited data. My suggestion would be to just leave the 600 row table on the dashboard if it provides value to the end user because performance really shouldn't be an issue.

    If I solved your problem, please select "yes" above

  • DavidChurchman
    edited September 2023 Answer ✓

    Is there any kind of grouping that would be useful? I find with large tables, it's helpful to start with a grouping variable and check off "show sub-total rows", which allows you to collapse the groups and help them navigate more quickly around the table by expanding/collapsing those groups.

    My understanding of 'dynamic paging' is it's not a feature your turn on or off, but rather it basically waits to load the bottom of your table until you get close to the bottom of your table, so it's not actually loading all 600 rows until a user scrolls far enough down to necessitate it.

    Please 💡/💖/👍/😊 this post if you read it and found it helpful.

    Please accept the answer if it solved your problem.

Answers

  • ColemenWilson
    edited September 2023 Answer ✓

    Is page performance your only concern? If so, have you tested the performance with all 600 rows? We have pages with table cards with that many rows and performance doesn't seem to be an issue at all. If you really don't want to have the 600 row table card on the page, you could change the interaction of the card at the dashboard level so that clicking it takes the user to a different card (the one with all 600 rows) but at the dashboard level it could be a separate card that has limited data. My suggestion would be to just leave the 600 row table on the dashboard if it provides value to the end user because performance really shouldn't be an issue.

    If I solved your problem, please select "yes" above

  • DavidChurchman
    edited September 2023 Answer ✓

    Is there any kind of grouping that would be useful? I find with large tables, it's helpful to start with a grouping variable and check off "show sub-total rows", which allows you to collapse the groups and help them navigate more quickly around the table by expanding/collapsing those groups.

    My understanding of 'dynamic paging' is it's not a feature your turn on or off, but rather it basically waits to load the bottom of your table until you get close to the bottom of your table, so it's not actually loading all 600 rows until a user scrolls far enough down to necessitate it.

    Please 💡/💖/👍/😊 this post if you read it and found it helpful.

    Please accept the answer if it solved your problem.