EPIC: Grid Cleanup

[mofojed]

Clean up some things in the Grid components

• Create allRowHeights and allRowYs maps #316
• Remove context from GridMetricState - doesn't need to be included, can include the font width map in the state
• Remove static GridRenderer values and move to GridTheme (DEFAULT_FONT_WIDTH, DEFAULT_EDGE_RADIUS, ACTIVE_CELL_BORDER_WIDTH)
• Grid with moved columns copies in incorrect order #597
• Grow selection on drag behaviour is inconsistent #572
• Vertical scroll bar can be drawn without handle #561
• Quick filter shortcut with frozen columns focuses frozen column and scrolls to front #555
• Collapsed quick filter bar display issues #554
• Table horizontal scroll is inconsistent #540
• Moving a wide column causes problems in Grid #437
• Resizing columns hidden by layout hints snaps incorrectly #526
• Rename groupedColumns used in rollups/tree tables #558
• Grid isStuckToBottom prop doesn't work correctly on mount if rowCount doesn't increase #581

[mattrunyon]

I think 1 way of cleaning up the API would be to make public methods use visible row/column or model row/column as parameters and rarely use other things unless necessary

For example, getting cached truncated string requires the user to pass the width of the text area in the cell. That could be determined from the cell coordinates to check the cache rather than the user calculating it.

Also maybe find a cleaner way to override/plugin to grid. Maybe we consider using multiple canvases for layers to make it easier to target specific areas (header, background, content, etc.). Making it simpler to customize would be a nice plus. But right now you need to do things like take the header height into account when trying to draw a row/button.

One idea would be to support middleware functions like ExpressJS uses for handing web server requests. We could have a defined set of steps that you can interject your own calls w/o needing to add the code to the renderer directly. Instead you could register things like onBeforeContent or onBeforeBackground. Idk, might not help that much or cause unexpected rendering problems.

It's somewhat annoying that to make a mouse handler draw something I need to also add code to the renderer and potentially IrisGrid. Maybe it makes more sense to have defined events/methods like onCellHover that can be added and the renderer always calls these events when necessary. But even then if you want a special background on hover vs a content change you would need some way to handle both.

[mattrunyon]

It might be beneficial to set metrics like gridX and gridY in the render methods, although there may be issues with doing it this way.

The idea is there's some metrics.incrementX(10) or metrics.incrementY(30) which is called during the render steps for anything that should shift the remaining content draws. Currently, there are multiple items that add to gridY like header, sort bar, reverse bar, and quick filters. Quick filters uses gridY to draw itself. The sort and reverse bars don't. This causes some issues with consistent drawing as I'm adding column groups.

Instead, the metric could be incremental so each draw step updates with how much space it took and then each part's draw only needs to worry about the existing gridY value at the time of draw.

An alternative would be to adjust the rendering methods to not calculate their own translates/offsets and instead have them add offsets after they're rendered. So drawColumnHeaders draws its headers and then does a context.translate(0, columnHeaderHeight) as its final call. Then gridY is only needed for hover/event handling I believe