Comment 3 for bug 1615781

Big proposed change incoming!

This branch rewrites the Angular eg-grid markup to use tables instead of divs:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sleary/LP1615781-eg-grid-tables

This introduces significant changes to the way column size, alignment, wrapping, and tooltips are handled. Aside from the accessibility benefits, the advantage of using tables is that we can let the browser set the column sizes automatically based on the contents. Text wraps automatically and does not show a tooltip. In other words, we assume that you should see all the data in the table cell.

All columns have a set of class names derived from the IDL field name, path, and datatype. This will allow us to write very precisely targeted styles for specific columns. There is some styling in place for certain columns, especially barcodes and numbers, which I have detailed here:
https://wiki.evergreen-ils.org/doku.php?id=dev:eg-grid:styling

You can resize columns on the fly. Each column has a blue resize slider, visible on hover/focus near the right edge of the column header. See below for detailed notes on how this works.

While this work was undertaken primarily to address the accessibility issues with div-based grids, the tables necessitated a rewrite of the column width controls, since the old flex=N sizing mechanism no longer applies. This branch therefore includes fixes for several other bugs related to column width and tooltips:

Bug 1778311 Web Client - Columns Can't be Resized on the Fly
Bug 1802169 Grid Column Headers too narrow
Bug 1858684 Angular grids: filter UI wider than grid columns
Bug 1878634 Show full column heading on mouseover in web client grids
Bug 1963708 Item Table has Confusing Hover Display Text
Bug 2057692 Grid column and action menu config dropdowns should allow multiple changes at once
Bug 1965835 Grid Configurations require a relog to apply as expected

This work makes it much easier to address bug 1645862, web client: Set default widths for some grid columns.

Since the Holdings View was the first thing most people wanted to look at when I initially demonstrated this work, I have included a commit that corrects the indentation in the locations / barcode column. We might want to separate this for backporting.

This branch does not change the underlying logic of grids, other than replacing the [flex] input with a character-based [size]. The column management component has been heavily revised to use tables in its own display, to reflect the new options, and to add drag and drop for rearranging columns. The old column width component has been removed.

I anticipate all this will need further refinement! Please let me know what you think.

The nitty gritty details…

Resizing columns:

You can either use the mouse or tab over to the slider using the keyboard and then move it with the left or right arrow keys. You can also set the width as a number of characters using the Manage Columns dialog. The character count will reflect changes you’ve made using the slider, but it does not auto-save; you will need to save grid settings from the settings menu or the Manage Columns dialog. You can reset a column to its default, auto-calculated width by deleting the character count in the dialog.

Note one quirk: if you use the slider on the rightmost column (or a column where all the columns to the right are already as narrow as they can possibly be), the column will get bigger as you are dragging your mouse, but the additional width will come from the *left* side, since that is the only side where the table sees available space. This looks visually wrong–you’re moving your mouse to the right, but the right edge stays in place while the left edge moves away from you. I don’t have a good solution for this right now without losing the magic of auto-calculated column widths. I will keep looking for a way to make the visuals match the user movement, but we might have to live with the trade-off unless someone has a brilliant solution in their back pocket.

Sometimes, there just isn’t enough room in the table to make columns bigger. There is a resize handle below the table that lets you make the entire table area wider, even if that introduces a scrollbar. This is not saved as part of the grid settings; the settings are assumed to contain column-related data, and I have not rewritten it to support things that apply to the grid as a whole.

Filter buttons:

The word “filter” has been removed from the filter buttons and the icon is now larger (the minimum button size required by WCAG). This should allow you to make columns much narrower in most cases. However, the table currently does not allow you to shrink a column beyond the size of the smallest word in the header. I plan to refine this in the future.

Drag and drop column reordering:

In Chrome/Edge, you will have to grab the column header text to initiate drag and drop; you can’t grab the free space in the header anymore. I hope to be able to fix this in the future.

Overflow vs. truncation:

The toolbar button that previously let you expand rows does the opposite here: it lets you truncate rows to a single line, in which case the tooltips return. Because CSS overflow rules are very different in tables, we can no longer show the ellipsis on truncated text. Instead, a dashed border appears between columns.

Anticipated Q: Can we have this in AngularJS?

A: Maybe. The HTML and CSS should be straightforward enough, and that will get us a lot of the automatic column size improvements, but someone more familiar with AngularJS than I am will need to examine the mouse movement subscriptions in grid-header.component.ts ngAfterViewInit() and see what you think about the resize controls. That piece and its associated keyboard functionality and CSS unit trickery represent more work than the rest of this branch combined. (There were many, many iterations before the adapted drag-and-drop solution noted in the comments.)

Two additional notes for developers:

Note the unusual selectors in the grid-body and grid-header components. I am open to other ways of accomplishing this. It’s essential that we not introduce interstitial custom elements into the table markup.

Both breakWords() and the uses of replaceAll() may be useful elsewhere, if we want to turn them into format pipes.