Support for multiple regions in GridSelection and colors for each

glide-data-grid currently supports cell selection, range selection, row selection, and column selection.

// https://github.com/glideapps/glide-data-grid/blob/main/packages/core/src/data-grid/data-grid-types.ts
export interface GridSelection {
    readonly cell: readonly [number, number]; // cell selection
    readonly range: Readonly<Rectangle>; // column selection
}

export class CompactSelection {
  ...


}

// https://github.com/glideapps/glide-data-grid/blob/main/packages/core/src/data-grid/data-grid.tsx
readonly selectedRows?: CompactSelection;
readonly selectedColumns?: CompactSelection;
readonly selectedCell?: GridSelection;

However, those selections given as props are limited when representing selections that originate from interactions outside of the normal current grid and when customizing the colors and fill of individual selections.

As an example / application from google sheets, the selections come from the active input box, and can be all different types and colors.

Would it possible for this library to support that? As a quick sketch, I think it could look like this

readonly selectedRows?: CompactSelection;
readonly selectedColumns?: CompactSelection;
readonly selectedCell?: GridSelection;
readonly selections?: ((CompactSelection | GridSelection) & SelectionStyle)[];

export interface SelectionStyle {
  border?: string // css equivalent
  backgroundColor?: string // css equivalent
}

And then selections would only need to be passed as a prop into drawGrid.

[jassmith]

Goals

Allow the user to highlight multiple areas of the grid to indicate related cells and regions.

Implementation Details

export interface GridSelection {
    readonly cell: readonly [number, number];
    readonly range: Readonly<Rectangle> | readonly Readonly<Rectangle>[];
    readonly highlights: {
        readonly range: readonly Readonly<Rectangle>;
        readonly color?: string;
        readonly key? string;
    }[];
}

There are a variety of subtleties to this that I think are worth discussing.

Why not just use a single array of ranges?

The range in the GridSelection is basically a special highlight. It is the highlight which can be mutated via the keyboard. If you press shift+arrow keys it is the highlight which changes. If you press copy, it is the highlight whose contents are to be copied. It is also the only highlight which must contain the selected cell.

How does the primary range/selection get a color?

From the theme like it does now. The others get passed colors.

What about remapped ranges?

This might be a pipe dream to make this totally transparent. At the moment my thinking is that the sorting hook can also provide getCellContent, getCellsForSelection, as well as handle all events to deal with selection. Selection then needs to be mangled/demangled based on the sort index map.

I don’t immediately see why it won’t work, but I didn’t see why column sorting couldn’t be totally transparent until I tried to implement it either.

Is this backwards compatible?

Kind of? At the very least all existing implementations will continue to work. Any library which is based on an older version of the code prior to this change may be incompatible with any code that uses the newly expanded type however. Effectively the answer is yes for applications, no for libraries.

Tags

I think it would be very useful for each highlight region to have a tag. If either the top or the bottom of the region (prefer top) is visible, we could draw a tag labeling. Problem here is I need to think very carefully about how this would impact blitting. At the bare minimum we would need to be careful when doing a damage draw that is right below one of these highlights.

Do highlight regions also need to support lists?

Technically to make these work with transparent sorting we would need to allow them to be broken up as well. However this is a feature that is only needed in very specific cases and I’m not sure we don’t just disable these whenever temporary sorting/filtering is enabled. Conversely these are in fact consumption only as far as DataEditor is concerned so breaking them up simply by creating a much larger list where some of them have the same color and making sure that we merge nearby ranges with the same color by treating the color as a key would also be sufficient.

This has the unfortunately side effect of slightly leaking this behavior if a developer were to add two highlight ranges next to each other which have the same associate color. To resolve this we would need to force a key parameter as well. It could be optional and transparent transform hooks could set it if its not already set. The key would allow for a hard line between adjacent highlights with the same color. Anything without a key will be assigned a random key during normalization.

Issues

• No method for providing a mechanism to support drawing dashed lines.
• How does this interact with multiple overlapping highlights? Do the colors blend? What blend mode? Also ew…
• If two highlight regions are overlapping how do they outlines get their colors? They can’t really blend.
• Can we draw this performantly? I suspect yes but I’m not 100% sure.

Version bump requirements

Bare minimum minor version bump. There is a reasonable argument to be made for major version.

[jassmith]

Fixed in 4.0.0