Column show/hide for the overview editors, with mobile defaults - #1564
Column show/hide for the overview editors, with mobile defaults#1564barrulus wants to merge 3 commits into
Conversation
Large editors render every row into the DOM at once, which is slow on big maps. Each editor now renders at most one page (100 rows) via a headless table core (src/components/dialog/table.ts): sorting and footer totals cover the full dataset, the page resets on open/filter/sort, and the footer pager fills the table width without widening fit-content dialogs. Full-dataset sorting helpers extend src/components/dialog/sorting.ts. No window globals; helpers are imported.
✅ Deploy Preview for afmg ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Cool, but some columns are out of place and the last one can get cut. We probably need to get rid of the current approach with grid-template-columns and use normal table/grid with strictly-defined columns width in data. Show columns button: can it be added to the header? |
| <div data-tip="Click to sort by state treasury. Click on a value to view and edit taxes" class="sortable hide" data-sortby="treasury">Treasury </div> | ||
| <div data-tip="Click to sort by state type" class="sortable alphabetically hidden show hide" data-sortby="type">Type </div> | ||
| <div data-tip="Click to sort by state expansion value" class="sortable hidden show hide" data-sortby="expansionism">Expansion </div> | ||
| <div data-tip="Click to sort by state name" class="sortable alphabetically" data-sortby="name" data-col="name">State </div> |
There was a problem hiding this comment.
do we need data-sortby="name" and class="sortable alphabetically" now? Can be moved to the table COLUMNS definition as well.
| } | ||
|
|
||
| const STATE_COLUMNS: EditorColumn[] = [ | ||
| { key: "name", label: "Name", hideable: false }, |
There was a problem hiding this comment.
We can add mote params here, incl. data accessor, UI value formatter, sorting type, default sorting and so on.
…1469/Azgaar#1564) Ports the paginated-table column show/hide stack onto the fork's customized editors: burgs keeps megalopolis badges, the skyburg button, GL label rebuild hooks and the altitude CSV column; states keeps the brush/demote/merge panel. The fork's older per-editor pagination scaffolding is replaced by the shared table.ts helpers. Dialog widths use the fork's fitContent() helper for Firefox.
|
Agreed on the direction. The misalignment and the cut-off last column both come from the header and rows being two separate layouts aligned by hand-tuned grid-template-columns, and the width-scaling code exists only to patch over that. I'll rework it the way you describe: the COLUMNS registry becomes the single source of truth (width, accessor, formatter, sort type, default sort, hideable), the header is generated from it (so data-sortby/sortable markup goes away), and rows share the header's grid tracks so alignment is exact and a fr-track fills leftover space with no measuring code at all. I will rework all of this here in this PR. |
These editors rendered before configuring their dialog, so the render's width refit initialized the widget with the default resizable: true and the opener's resizable: false then destroyed that widget. Touch-punch unbinds by shared proxy guid, so the destroy stripped the draggable's touch handlers too, leaving the dialogs undraggable on touch devices. Renders now only refit an existing dialog (fitDialogIfExists) and the opener's single configuring call creates the widget.
6df76de to
e363c0e
Compare
|
there is an issue in moving from the fork to FMG. Don't waste cycles on this until I have unpacked it and cleaned it up |
e363c0e to
29631b5
Compare
|
This has worked out really well. If you like how this is done, I will extend it to the remaining editors byond these 6 targeted ones |
|
Generally yes, it should be expanded to all controllers, but it doesn't have to be done now. |
I have the plan to do this in place already, I just didn't want to hit go on all of that until you had signed off on the mechanics :) All other editors I touch will end up with the same mechanics and utilise the same shared utils |
2 participants
Reworked to the data-driven approach you asked for. The header is now generated from a per-editor column registry, and header and rows share one declared track list, so the hand-tuned
grid-template-columnsand all the width-measuring JavaScript are gone.How it works. Each of the six paginated editors declares a column registry — key, label, width, fill, tooltip, sort accessor, sort type, default sort, hideable, mobile-hidden.
buildTracksturns the visible columns into one CSS track list published on the dialog as--table-columns;renderEditorHeadergenerates the header from the same registry; header and rows are grids consuming that variable. Sorting reads each column'ssortBy, sodata-sortbyand thesortableclasses are no longer hand-written markup, and the per-editor sort-accessor records are gone.Three consequences worth calling out:
The columns button now renders in the header's trailing cell instead of the bottom toolbar.
Mobile defaults are unchanged from the previous revision: 20 rows per page, bulkier columns hidden, filter and toolbar rows stacked. Defaults only — an explicit choice wins and persists per editor.
The first commit is an independent fix: these editors rendered before configuring their dialog, so the render-side width refit created the widget with the default
resizable: true, and the opener'sresizable: falsethen destroyed it. touch-punch unbinds by shared proxy guid, so that destroy also stripped the draggable's touch handlers and left the dialogs undraggable on touch devices. Renders now only refit an existing dialog.I did not include a
formatteron the column model — rows are still built by each editor's own template, so it would have no consumer until cell rendering itself becomes generic. The model has room for it when that happens.Tests cover the pure logic (
buildTracks, pagination, column persistence, sorting) under the existingenvironment: "node". A few DOM-level assertions are omitted rather than adding a jsdom dependency or changing the vitest config in this PR — happy to add them if you'd like the test setup extended separately.