Optimize scrolling behavior of Discover table

[AMoo-Miki]

Description

This change addresses three problems by lazy-loading additional rows when infinitely scrolling the table:

1. While a page size of 10 helped speed up rendering, scrolling users encountered the bottom of the table too often. By continuing to load a page but lazy-loading 4 additional pages (for a total of 5), that frequency is reduced.
2. As new rows were mounted, their content pushed cell boundaries and caused column widths to change; this was unpleasant and distracting. After the first page is loaded, the columns are allowed to adjust to the content and then the dimensions are fixed to prevent that.
3. Allow the paginated experience have the 50 pages that were previously allocated to it.

Issues Resolved

TBA

Screenshot

Before

Before.mov

After

After.mov

Changelog

• skip

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[AMoo-Miki]

24px for the button + 4px for a right padding = 28px

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.66%. Comparing base (d2d410b) to head (0e909d6).
Report is 49 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #6683       +/-   ##
===========================================
+ Coverage   32.93%   67.66%   +34.72%     
===========================================
  Files        2260     3415     +1155     
  Lines       45769    66886    +21117     
  Branches     7200    10884     +3684     
===========================================
+ Hits        15075    45259    +30184     
+ Misses      29984    19025    -10959     
- Partials      710     2602     +1892     

Flag	Coverage Δ
Linux_1	33.18% <ø> (+0.24%)	⬆️
Linux_3	45.23% <ø> (?)
Linux_4	34.85% <ø> (?)
Windows_1	33.20% <ø> (?)
Windows_2	55.56% <ø> (?)
Windows_3	45.23% <ø> (?)
Windows_4	34.85% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kavilla]

@AMoo-Miki for the test failure, I think it might be worth to reduce the number instead of having the test build in the non-optimized version. Versus modifying your logic for the test to pass.

[AMoo-Miki]

@AMoo-Miki for the test failure, I think it might be worth to reduce the number instead of having the test build in the non-optimized version. Versus modifying your logic for the test to pass.

Since retry.try has a huge timeout of 2 mins, it is safe to assume that the lazy-loading would have run in the given time to render the 50 rows that we would expect.

[kavilla]

@AMoo-Miki for the test failure, I think it might be worth to reduce the number instead of having the test build in the non-optimized version. Versus modifying your logic for the test to pass.

Since retry.try has a huge timeout of 2 mins, it is safe to assume that the lazy-loading would have run in the given time to render the 50 rows that we would expect.

oh so you are saying it's an actual failure? i thought maybe the test might have just been actually expecting 50 rows that aren't in fully view but since we optimized it wasn't able to find those rows unless it was scrolled with

[kavilla]

one test is flaky. and the link checker has been fixed. lgtm!!