feat: DH-19413: Support expandable columns in grids v0.85

[vbabich]

Merge this after #2537

[codecov]

Codecov Report

❌ Patch coverage is 71.05263% with 33 lines in your changes missing coverage. Please review.
✅ Project coverage is 47.77%. Comparing base (e3860a7) to head (19cc746).

Files with missing lines	Patch %	Lines
packages/iris-grid/src/IrisGrid.tsx	66.66%	14 Missing ⚠️
packages/iris-grid/src/IrisGridMetricCalculator.ts	73.46%	13 Missing ⚠️
...d/src/mousehandlers/IrisGridContextMenuHandler.tsx	50.00%	4 Missing ⚠️
packages/iris-grid/src/IrisGridModel.ts	0.00%	2 Missing ⚠️

Additional details and impacted files

@@                Coverage Diff                @@
##           release/v0.85    #2524      +/-   ##
=================================================
+ Coverage          47.36%   47.77%   +0.41%     
=================================================
  Files                710      711       +1     
  Lines              39527    39632     +105     
  Branches           10064     9901     -163     
=================================================
+ Hits               18721    18935     +214     
+ Misses             20751    20684      -67     
+ Partials              55       13      -42     

Flag	Coverage Δ
unit	47.77% <71.05%> (+0.41%)	⬆️

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.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mofojed]

Looks good overall, just the one comment about how the type predicate probably shouldn't only return true if hasExpandableColumns is true.

[mofojed]

We probably need to reset the calculated column width as well...
Really what we should do is allow for keys to be provided for both row and columns, and then methods can accept the keys instead of the model index... we're kind of gluing this on top by bringing the logic back up. Though I don't think we should do that all right now...
Though - I do think we can keep this contained in the IrisGridMetricCalculator, by overriding getMetrics, and doing something like:

  getMetrics(state: IrisGridMetricState): GridMetrics {
    const { model } = state;

    // Check the column name map to see if we need to update things

    const metrics = super.getMetrics(state);

    // Update column name map

    return metrics;
  }

I think that would simplify things...

[mofojed]

So we were discussing how this is a breaking change in GridMetricCalculator... and I'm just going to put some of my thoughts here for posterity.

• At some point we probably should refactor the Grid API and clean things up, like a v2. Like some of the points on our Discussion board: Grid V2 #587
• If I were to refactor GridMetricCalculator, I think I would remove the set/getters for user column width, and just pass that in as part of the state (like everything else). That would be more consistent.
  • Probably also refactor all methods to be protected - so you can override functionality, but discourage calling it directly... the metrics should be stored/shared outside of the calculator.
• However, I'm not exactly keen on doing all that for this change...
• I think for this change, just retain the model from getMetrics, and use that... and if you have somewhere that's getting called first, just add a new method with the new signature, e.g. setColumnWidthWithState()...

Thoughts?