feat: Partitioned Table UI Enhancements

[AkshatJawne]

Resolves #2079 ( Resolves #2066 , Resolves #2103 , Resolves #2104 , Resolves #2105 , Resolves #2106 , Resolves #2107 , Resolves #2108 , Resolves #2109 , Resolves #2049 ), Resolves #2120, Resolves #1904

Changes Implemented:

• Replaced keysTable with baseTable
• Made small UI changes to differentiate between Partition Table and Partition-aware source table
• Allow double clicking to set partition
• Add context menu action to set partition

Sample Visuals:
Default Partition Table View

Default Partition-aware source table view:

[AkshatJawne]

Looking into unit test failures

[AkshatJawne]

BTW, ready for review

[codecov]

Codecov Report

Attention: Patch coverage is 23.72881% with 90 lines in your changes missing coverage. Please review.

Project coverage is 46.68%. Comparing base (e3aa392) to head (e588409).
Report is 16 commits behind head on main.

Files	Patch %	Lines
packages/iris-grid/src/IrisGrid.tsx	5.12%	37 Missing ⚠️
...ckages/iris-grid/src/IrisGridPartitionSelector.tsx	52.27%	20 Missing and 1 partial ⚠️
...sehandlers/IrisGridPartitionedTableMouseHandler.ts	17.64%	14 Missing ⚠️
...ges/iris-grid/src/IrisGridPartitionedTableModel.ts	0.00%	10 Missing ⚠️
packages/iris-grid/src/IrisGridTableModel.ts	0.00%	4 Missing ⚠️
...d/src/mousehandlers/IrisGridContextMenuHandler.tsx	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2110      +/-   ##
==========================================
+ Coverage   46.60%   46.68%   +0.08%     
==========================================
  Files         679      691      +12     
  Lines       38408    38587     +179     
  Branches     9687     9622      -65     
==========================================
+ Hits        17901    18016     +115     
- Misses      20455    20560     +105     
+ Partials       52       11      -41     

Flag	Coverage Δ
unit	46.68% <23.72%> (+0.08%)	⬆️

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.

[AkshatJawne]

Looking into failures here

[AkshatJawne]

Weird that the failures are only occurring on chromium, but I believe the reason of the failure is that we expect to have the pickers accessible in 1.5s, but now, with the new logic, the pickers are disabled while the partitionConfig.mode === 'empty', which in some cases (like the vid below), is not the case.

The reason we do this is so that when we have an empty partition table, we wanted to have the pickers disabled. But even for a table with rows, the table will have 0 rows of length (and thus, will be considered empty) momentarily.

We could either change the benchmark to be 20000ms instead of 15000ms, or we could look at adding a specific "temporarily empty" config mode, which would somehow differ then the "empty" mode (which would now act as more of a forever empty mode).

The latter will be difficult to implement though, since the event listener listens for when the table is updated and then changes the mode accordingly, so I am not sure how before the event, it will differentiate between a table that will be forever empty, and one that is just empty until the data loads in.

@mofojed @dsmmcken any thoughts?

screen-capture.4.webm

[mofojed]

We've already got the loading state for when it's still loading. The empty state is for when the table is empty, there's no need for a forever empty state; an empty table could eventually tick in data (it could be in one second, one minute, one hour, we don't really know).
That being said - the failures in the e2e tests are not with the partitioned tables? Where are you seeing that the disabled pickers is affecting the e2e tests? Look at the report attached: https://github.com/deephaven/web-client-ui/actions/runs/9845185336/artifacts/1682155129
Looking at the report it's looking for a context menu that does not appear for some reason.

[mofojed]

I'm going to need a bit more time to think about this one.

[mofojed]

I'm going to need to think about this a bit more - we should be showing the loading spinner while it's still loading.

[AkshatJawne]

@mofojed, what if we did something like this?

From line 4365-5370 of IrisGrid.tsx, where we could now set the show of the loading text based on loadingSpinnerShown or the configMode === "loading"

[AkshatJawne]

No actually, that does not fix the issue we are facing with the spinner, ignore.

[AkshatJawne]

Been doing some more investigations, the firefox and cjromium failures here are not consistent. On one run they fail, but then if I re-run those jobs, they pass. The inconsistent behaviour makes me think there may be a race condition or some weird code circumstance in the code responsible for rendering the context menu.

The only change I made to the Context Menu was adding the View Constituent Table option, but I am unsure why that would result in the whole context menu not loading, need to dig more.

[mofojed]

This is looking good, but the e2e tests are failing: https://github.com/deephaven/web-client-ui/actions/runs/9977913349/job/27578476354?pr=2110
I think it's because of our early return in rebuildFilters() if the filters aren't set, causing it to right-click in the test before the table has appeared.
We can debug in our 1:1, seems kind of tricky

[AkshatJawne]

Yeah I have been trying to debug the e2e failures, but it is slightly tricky, will continue to debug and then we can debug together as well in our 1:1, will make the requested change with -1 rn.