tablewalk 0.0.1

package/dist/client/record.js

@@ -0,0 +1,707 @@
+/**
+ * The record view: one row, its fields, and everything that points at it.
+ *
+ * The two panels are fetched together because they are independent, and
+ * waiting for the reverse-reference counts to show the field list would make
+ * every record open feel slower than it is.
+ */
+import {
+  api, el, findTable, go, keyFilter, keyOf, labelPath, loadJson, pageView, primaryKey, quote,
+  refsTo, renderCrumbs, rowLabel, rowView, saveJson, setExplain, state, tableView, toast,
+} from './core.js';
+import { copyPosition, positionOf } from './handoff.js';
+import { syncHash } from './url.js';
+import { refJump, valueNode } from './value.js';
+import { pagesFor } from './page.js';
+import { canEditRow, editable, pendingBar, whyNotEditable } from './write.js';
+import { deleteButton } from './delete.js';
+import { renderGrid } from './table.js';
+import { activeDraft, editLayoutButton, fieldPathsOf, hasSavedTemplate, listSectionsOf, templateFor } from './template.js';
+import { placeholder, recordSkeleton, relatedSkeleton } from './skeleton.js';
+
+/** This record's page, with this record already chosen as its root. */
+async function openAsPage(entry) {
+  let pageId = `suggested:${entry.table}`;
+  try {
+    const [configured] = await pagesFor(entry.table);
+    if (configured && !configured.error) pageId = configured.id;
+  } catch {
+    // A config that cannot be read still leaves the suggested page.
+  }
+  go(pageView(pageId, entry.table, entry.key, entry.label), 'push');
+}
+
+export async function renderRow(entry, content) {
+  const table = findTable(entry.table);
+
+  /* Whether anything *can* point here is a fact about the schema, known
+     before any request — so a table with nothing pointing at it costs no
+     round trip to discover that. */
+  const canBeReferenced = refsTo(entry.table).length > 0;
+  const grid = el('div', { class: canBeReferenced ? 'record' : 'record record-solo' });
+  content.append(grid);
+
+  const heading = () => el('h3', { class: 'record-heading' }, [
+    el('span', { text: `${entry.table} · ${entry.label}` }),
+    /* The record you are on, as a page — the same root, everything around it
+       at once. This is the shortest useful path into the feature: you are
+       already looking at the customer, and one click adds the counts and the
+       lists without choosing a root or writing any config. */
+    el('button', {
+      type: 'button',
+      class: 'ghost record-as-page',
+      title: 'Everything about this record on one page',
+      text: 'As a page \u2192',
+      onclick: () => void openAsPage(entry),
+    }),
+    el('button', {
+      type: 'button',
+      class: 'ghost',
+      title: 'The row\u2019s key, its shape and how to read it over MCP \u2014 not its values',
+      text: 'Copy for agent',
+      onclick: () => void copyPosition(
+        positionOf(state, entry, { record: { key: entry.key, label: entry.label } }),
+        toast,
+      ),
+    }),
+    editLayoutButton(entry.table),
+    // Only where the server would accept it; see canDelete.
+    deleteButton(table, entry.key, entry.label),
+  ].filter(Boolean));
+
+  const fieldsPanel = el('div', { class: 'panel' }, heading());
+  grid.append(fieldsPanel);
+
+  /* The placeholder is built from the layout this record is about to be drawn
+     with, so the headings and the two-column field grid are already where they
+     will be. The page does not jump when the row lands; it fills in. */
+  const template = activeDraft(entry.table) ?? templateFor(entry.table);
+  const doneFields = placeholder(fieldsPanel, () =>
+    recordSkeleton(
+      template.sections
+        .filter((s) => s.kind === 'fields' && !s.off)
+        .map((s) => ({ title: s.title, count: s.paths.length }))
+        .slice(0, 5),
+    ));
+
+  /* The relationship index lives in its own column, always visible.
+
+     It was a horizontal strip under the record for a while, which put the
+     list of what relates to this row below a screenful of fields — so
+     finding out what a record connects to required scrolling past the record.
+     A column keeps it in view, and a vertical list has room for a dozen
+     relationships where a tab strip wraps. */
+  const relatedPanel = canBeReferenced
+    ? el('div', { class: 'panel related-panel' }, el('h3', { text: 'Related' }))
+    : null;
+  if (relatedPanel) grid.append(relatedPanel);
+  const doneRelated = relatedPanel
+    ? placeholder(relatedPanel, () => relatedSkeleton(refsTo(entry.table).length))
+    : () => {};
+
+
+  const filter = keyFilter(entry.key);
+
+  /* Both sides are fetched together: the field list and the reverse-reference
+     counts are independent, and waiting for the second to show the first
+     would make every record open feel slower than it is. */
+  /* The record runs as a one-row view rather than a plain query.
+
+     That is what lets a field section hold `customer_id.name` — the value
+     lives on another table, and only the view compiler knows how to reach it.
+     It also means a record page and a list view are the same machinery
+     pointed at different questions, rather than two renderers that will
+     disagree about what a joined column is called. */
+  // `template` is resolved above, before the placeholder, because the
+  // placeholder is built from it. The in-progress draft wins while the builder
+  // is open, so the record on screen is the layout being edited rather than
+  // the last one saved.
+  const paths = fieldPathsOf(template);
+  /* The row's name is fetched whether or not the layout shows it.
+
+     For a table whose name lives one hop away — employee, named by
+     `party_id.display_name` — a layout that dropped that field would also
+     silently rename every heading and crumb back to the key. The label is a
+     property of the row, not of the layout, so it rides along hidden, the
+     same way a child row's key does. */
+  const namePath = labelPath(table);
+  const fetched = namePath && !paths.includes(namePath) ? [...paths, namePath] : paths;
+  const [rowResult, refResult] = await Promise.allSettled([
+    api('/api/view/run', {
+      view: {
+        id: `record:${entry.table}`,
+        name: entry.table,
+        base: entry.table,
+        columns: fetched.map((path) => ({ path })),
+        filter: { groups: [Object.entries(entry.key).map(([path, value]) => ({ path, op: '=', value }))] },
+        limit: 1,
+      },
+    }),
+    canBeReferenced ? api('/api/references', { table: entry.table, key: entry.key }) : Promise.resolve(null),
+  ]);
+
+  doneFields();
+  if (rowResult.status === 'rejected' || !rowResult.value.rows.length) {
+    fieldsPanel.replaceChildren(el('h3', { text: entry.table }), el('p', { class: 'note', text: 'That row is no longer there.' }));
+  } else {
+    /* Filtered, because replaceChildren stringifies a null argument into the
+       text "null" — unlike el(), which skips it. The pending bar is absent
+       most of the time, so this printed a stray "null" above every row. */
+    fieldsPanel.replaceChildren(
+      ...[
+        heading(),
+        pendingBar(table, entry.key, (opts) => (opts?.inPlace ? updatePendingBar(table, entry) : go({ ...entry }, 'replace'))),
+        fieldList(table, rowResult.value.rows[0], entry, template, rowResult.value.resolved),
+      ].filter(Boolean),
+    );
+    setExplain(rowResult.value.sql.text);
+
+    /* A row reached by a link knows only its key, so its crumb reads "1002".
+       Now that the row is here, the readable label is, too. */
+    const readable = rowLabel(table, rowResult.value.rows[0]);
+    if (readable && readable !== entry.label) {
+      entry.label = readable;
+      /* Only the label text, not the heading's contents. Setting
+         `textContent` on the whole heading replaced the Layout button with a
+         string — so a row reached by key, which is every row reached from a
+         link, lost the control the moment its name arrived. */
+      const label = fieldsPanel.querySelector('.record-heading > span');
+      if (label) label.textContent = `${entry.table} · ${readable}`;
+      renderCrumbs();
+    }
+  }
+
+  /* The children, as tables on the page.
+
+     The Referenced-by panel beside this is the index — counts, and a way to
+     jump. These are the data. A work order that says "5 parts" and makes you
+     click to see them is answering a question nobody asked; the reason you
+     opened the record was usually to read them.
+
+     One query per relationship, keyed on this row — not one per child row,
+     and not a join, which would multiply the record away. */
+  void renderChildTables(
+    entry,
+    fieldsPanel,
+    relatedPanel,
+    template,
+    refResult.status === 'fulfilled' ? refResult.value : null,
+  ).finally(doneRelated);
+
+}
+
+/* The column grouping that used to live here — a third client copy of
+   groupOwnColumns from shared/recordview.ts, with its own hand-written date
+   test — had no callers left once the record started rendering from its
+   template. A mirror nothing runs still drifts, and is still read as though
+   it were the rule; the one copy now lives in template.js. */
+
+function fieldList(table, row, entry, template, resolved) {
+  const editing = canEditRow(table, entry.key);
+  const blocked = whyNotEditable(table);
+  /* Typing must not re-render the whole panel — that would destroy the input
+     mid-keystroke and lose the caret. Only the pending bar is refreshed. */
+  const refresh = () => updatePendingBar(table, entry);
+  const wrap = el('div', { class: 'field-groups' });
+
+  /* The view runner names a joined column by its path, so the row is keyed
+     that way too. Indexed rather than searched, because a record with six
+     reference blocks would otherwise scan the column list once per field. */
+  const byPath = new Map((resolved ?? []).map((c) => [c.path, c]));
+
+  const sections = template.sections.filter((s) => s.kind === 'fields' && !s.off);
+  for (const section of sections) {
+    const list = el('dl', { class: 'fields' });
+
+    /* Labels are the last segment of a path — see `columnForPath` — which is
+       right while a block holds one table's fields and wrong the moment it
+       holds two. A section mixing `name` with `country_code.name` labelled
+       both of them "name", side by side, with nothing to say which was the
+       customer's. The builder does not produce that; a layout written by hand
+       easily does, and it is the first thing anyone seeds.
+
+       So the qualifier comes back only where it is doing work: a label that
+       occurs once is left alone, and one that collides is spelled out to the
+       hop that distinguishes it. */
+    const labels = section.paths.map((path) => columnForPath(table, path, byPath)?.label);
+    const collides = new Set(labels.filter((l, i) => l && labels.indexOf(l) !== i));
+
+    for (const path of section.paths) {
+      const resolvedMeta = columnForPath(table, path, byPath);
+      if (!resolvedMeta) continue;
+      const meta = collides.has(resolvedMeta.label)
+        ? { ...resolvedMeta, label: path }
+        : resolvedMeta;
+      const value = row[byPath.get(path)?.name ?? path];
+      /* Only the record's own columns are editable. `customer_id.name` lives
+         on another table, and letting it be typed here would write to a row
+         the page is not showing — which is the kind of surprise that makes a
+         write feature untrustworthy. */
+      list.append(fieldRow(table, { [meta.name]: value }, entry, meta, editing && !path.includes('.'), refresh));
+    }
+    if (!list.childElementCount) continue;
+
+    if (!section.title) {
+      wrap.append(el('section', { class: 'field-group field-group-plain' }, list));
+      continue;
+    }
+    wrap.append(el('section', { class: 'field-group' }, [
+      el('button', {
+        class: 'field-group-head',
+        type: 'button',
+        'aria-expanded': 'true',
+        onclick: (e) => {
+          const parent = e.currentTarget.parentElement;
+          const open = parent.classList.toggle('collapsed');
+          e.currentTarget.setAttribute('aria-expanded', String(!open));
+        },
+      }, [
+        el('span', { class: 'field-group-caret', 'aria-hidden': 'true', text: '▾' }),
+        el('span', { text: section.title }),
+        el('span', { class: 'field-group-count', text: String(list.childElementCount) }),
+      ]),
+      list,
+    ]));
+  }
+
+  if (blocked) wrap.append(el('p', { class: 'note', text: blocked }));
+  return wrap;
+}
+
+/**
+ * The column metadata behind a path.
+ *
+ * For the record's own column that is just the column; for a pulled-in one
+ * the compiler already resolved the type and nullability, and using its
+ * answer keeps the record and the grid agreeing about what a joined value is.
+ */
+function columnForPath(table, path, byPath) {
+  if (!path.includes('.')) return table?.columns.find((c) => c.name === path);
+  const resolved = byPath.get(path);
+  if (!resolved) return null;
+  return {
+    name: resolved.name,
+    /* Labelled by the last segment. The block's heading already says which
+       table these came from, so repeating `customer_id.` on every row inside
+       it is the qualifier stated twice — and it pushes the actual column name
+       out of a narrow label column. */
+    label: path.slice(path.lastIndexOf('.') + 1),
+    type: resolved.type,
+    nullable: resolved.nullable,
+    primaryKey: false,
+  };
+}
+
+/** One field: its name, its type, and whatever the value is best shown as. */
+function fieldRow(table, row, entry, col, canEdit, refresh) {
+  const value = row[col.name];
+  const isNull = value === null || value === undefined;
+  // The key identifies the row being edited and cannot be changed from under
+  // it, whatever the caller allows.
+  canEdit = canEdit && !col.primaryKey;
+
+  const dt = el('dt', {}, [
+    document.createTextNode(col.label ?? col.name),
+    el('span', { class: 'type', text: col.type.toLowerCase() }),
+    col.primaryKey ? el('span', { class: 'pk', text: 'key' }) : null,
+    /* NOT NULL is only shown while editing. On a filled field it says
+       nothing — the value is right there — and marking two thirds of a wide
+       record "required" is noise that makes the useful markers harder to
+       see. It becomes actionable the moment you can empty the field. */
+    !col.nullable && canEdit ? el('span', { class: 'req', title: 'NOT NULL', text: 'required' }) : null,
+  ]);
+
+  let dd;
+  if (canEdit && (isNull || !col.references)) {
+    dd = el('dd', {}, editable(table, row, col, entry.key, refresh));
+  } else if (isNull) {
+    dd = el('dd', { class: 'null', text: 'null' });
+  } else if (col.references && String(value) !== '') {
+    // A foreign key is the forward walk: jump to the row it points at.
+    dd = el('dd', {}, refJump(col.references, value));
+  } else {
+    dd = el('dd', {}, valueNode(col, value));
+  }
+
+  return el('div', { class: `field${col.references ? ' field-ref' : ''}` }, [dt, dd]);
+}
+
+/**
+ * Swap the pending-changes bar in place.
+ *
+ * Deliberately not a re-render: redrawing the field list while someone is
+ * typing in it replaces the focused input and throws away the caret position.
+ */
+function updatePendingBar(table, entry) {
+  const panel = document.querySelector('.record .panel');
+  if (!panel) return;
+  const existing = panel.querySelector('.pending');
+  const next = pendingBar(table, entry.key, (opts) => (opts?.inPlace ? updatePendingBar(table, entry) : go({ ...entry }, 'replace')));
+  if (existing && next) existing.replaceWith(next);
+  else if (existing) existing.remove();
+  else if (next) panel.querySelector('h3')?.after(next);
+}
+
+/** Rows to show inline before the section defers to its own page. */
+const INLINE_ROWS = 10;
+
+/**
+ * Render each incoming relationship as a table under the record.
+ *
+ * Deliberately after the fields and asynchronously: the record itself must
+ * not wait on a relationship that is slow, and a page that renders in two
+ * stages is better than one that renders late.
+ */
+/**
+ * Which relationship was last looked at, per table.
+ *
+ * Kept for the session so walking from one work order to the next lands on
+ * the same tab. Someone comparing the parts of six orders should not have to
+ * reselect parts six times.
+ */
+/**
+ * Whether empty relationships are folded away, per connection.
+ *
+ * Per connection rather than per table or per session: how many of a
+ * record's relationships are empty is a property of the schema — a wide,
+ * well-normalised one leaves most of them empty for most records — so the
+ * answer someone gives on one table is almost always the answer they want on
+ * the next. Defaults to showing everything, because a rail that quietly left
+ * things out would be a rail nobody could trust to be the whole list.
+ */
+const EMPTIES_KEY = 'tablewalk.related.hideEmpty';
+
+const hidingEmpty = () => Boolean(loadJson(EMPTIES_KEY, {})[state.activeConnection ?? '']);
+
+function setHidingEmpty(on) {
+  const all = loadJson(EMPTIES_KEY, {});
+  all[state.activeConnection ?? ''] = on;
+  saveJson(EMPTIES_KEY, all);
+}
+
+const lastTab = new Map();
+
+async function renderChildTables(entry, fieldsPanel, relatedPanel, template, references) {
+  /* Every path out of here settles the Related panel.
+     
+     It opens on "Counting…", and a return that left it there turned a record
+     with no related tables into one that looks like it is still loading —
+     forever. Saying "nothing" is an answer; a spinner that never stops is
+     not. */
+  const settle = (message) => {
+    if (!relatedPanel) return;
+    relatedPanel.replaceChildren(
+      el('h3', { text: 'Related' }),
+      el('p', { class: 'note', text: message }),
+    );
+  };
+
+  const sections = listSectionsOf(template);
+  if (!sections.length) {
+    settle(
+      refsTo(entry.table).length
+        ? 'This layout has no related tables. Add one under Layout.'
+        : 'Nothing points at this row.',
+    );
+    return;
+  }
+
+  const host = el('div', { class: 'record-children' });
+  fieldsPanel.append(host);
+
+  const results = await Promise.allSettled(sections.map(async (section) => {
+    const fk = state.schema.foreignKeys.find((f) => f.name === section.via);
+    if (!fk) return null;
+    const child = findTable(fk.from.table);
+    if (!child) return null;
+
+    /* Every column of the key has to match, which is what makes this correct
+       for a composite key rather than only for a single-column one. */
+    const conditions = fk.to.columns.map((parentColumn, i) => ({
+      column: fk.from.columns[i] ?? fk.from.columns[0],
+      op: '=',
+      value: entry.key[parentColumn],
+    }));
+    if (conditions.some((c) => c.value === undefined || c.value === null)) return null;
+
+    /* The joining column is dropped: every row here carries the same value
+       for it, so a column of it is a column of one repeated value. */
+    const columns = (section.columns ?? []).filter((name) => child.columns.some((c) => c.name === name));
+    const limit = section.limit ?? INLINE_ROWS;
+
+    /* The key is fetched whether or not it is shown.
+
+       A summary drops the primary key on purpose — a column of ids says
+       nothing about what distinguishes the rows. But the key is what a row
+       click navigates by, and a row that arrives without one produces a link
+       to `~invoice:undefined`: a dead end reached by clicking something that
+       looked live. So it is requested and then hidden, rather than not
+       requested. */
+    const key = primaryKey(child);
+    const fetched = columns.length ? [...new Set([...key, ...columns])] : undefined;
+
+    const fetch = async (offset) => {
+      const data = await api('/api/query', {
+        table: child.id,
+        filter: { groups: [conditions] },
+        columns: fetched,
+        limit,
+        offset,
+      });
+      /* Ordered by the layout, not by the query.
+
+         The key is fetched and hidden, so the returned column list is not the
+         chosen one — it had to be filtered. Filtering `data.columns` kept the
+         *database's* order, which was invisible while the only decision a
+         layout could make was which columns; the arranger can order them now,
+         and an arrangement that does nothing is worse than no arrangement. */
+      return columns.length
+        ? { ...data, columns: columns.filter((name) => data.columns.includes(name)) }
+        : data;
+    };
+    return { fk, child, data: await fetch(0), section, limit, fetch };
+  }));
+
+  /* Empty relationships stay, as disabled tabs.
+
+     This used to be the Referenced-by panel's job: "work_order via
+     supersedes_id — 0" is a real answer, and hiding it turns "nothing
+     supersedes this" into "this tool does not track that". Keeping them here
+     is what let the panel go, rather than saying the same thing twice in two
+     places. */
+  const rendered = results
+    .map((r) => (r.status === 'fulfilled' ? r.value : null))
+    .filter(Boolean);
+
+  if (!rendered.length || !relatedPanel) {
+    host.remove();
+    settle('Nothing points at this row.');
+    return;
+  }
+
+  /* Tabs rather than a stack.
+
+     Four relationships stacked push the record's own fields off the top of
+     the window, so reading the thing you navigated to means scrolling past
+     everything related to it. Only one of them is being read at a time
+     anyway; the rest are a menu, and a menu should be one row high. */
+  const counts = new Map(
+    (references?.references ?? []).map((r) => [r.constraint, r.count]),
+  );
+
+  /* Ranked by how much there is to read — but only when nobody has arranged
+     them. A derived layout lists relationships in schema order, which on a
+     wide table buries `stock_movement 7` under a run of zeroes that happen
+     to sort earlier; the rows someone came for should be at the top. A saved
+     layout's order is its author's, and stays exactly as written. */
+  if (!activeDraft(entry.table) && !hasSavedTemplate(entry.table)) {
+    const weight = (r) => counts.get(r.fk.name) ?? r.data.rows.length;
+    rendered.sort((a, b) => weight(b) - weight(a));
+  }
+
+  const hasRows = (r) => r.data.rows.length > 0;
+  /* A link's choice wins over this session's, since it is the more specific
+     statement: someone opened *this* link to see *that* relationship. */
+  const chosen = entry.tab ?? lastTab.get(entry.table);
+  let activeIndex = rendered.findIndex((r) => r.fk.name === chosen && hasRows(r));
+  // Opens on something worth reading rather than on an empty table that
+  // happens to sort first.
+  if (activeIndex < 0) activeIndex = rendered.findIndex(hasRows);
+  if (activeIndex < 0) activeIndex = 0;
+
+  const strip = el('div', { class: 'related-list', role: 'tablist', 'aria-orientation': 'vertical' });
+  const panel = el('div', { class: 'child-panel' });
+
+  /* Where each relationship has been paged to.
+
+     Kept per relationship rather than one shared page number, so switching
+     to another table and back returns to the page you were reading instead
+     of silently resetting to the first ten rows. */
+  const page = new Map();
+
+  const show = async (index, { scroll = false, chosen: byHand = false } = {}) => {
+    if (!hasRows(rendered[index])) return;
+    activeIndex = index;
+    lastTab.set(entry.table, rendered[index].fk.name);
+    /* Into the address bar when someone *picked* this table — "look at its
+       notes" is as worth sending on a record as it is on a page — and not
+       when the view opened on it by default. A default is not a choice, and
+       writing it would change the link of every record the moment it drew,
+       so two identical visits would produce two different URLs. */
+    if (byHand) {
+      entry.tab = rendered[index].fk.name;
+      syncHash();
+    }
+    [...strip.children].forEach((tab, i) => tab.setAttribute('aria-selected', String(i === index)));
+
+    const { fk, child, section, limit, fetch } = rendered[index];
+    const offset = page.get(fk.name) ?? 0;
+    const total = counts.get(fk.name);
+
+    /* Page one is already in hand from the initial load; later pages are
+       fetched. Re-fetching page one on every tab switch would make going
+       back to a table you just read cost a round trip to show what was
+       already on screen. */
+    const data = offset === 0 ? rendered[index].data : await fetch(offset);
+
+    const openAll = () => {
+      const conditions = fk.from.columns
+        .map((col, i) => `${col} = ${quote(entry.key[fk.to.columns[i]])}`)
+        .join(' and ');
+      go(tableView(child.id, `${child.id} ${conditions}`));
+    };
+
+    const turn = (delta) => {
+      page.set(fk.name, Math.max(0, offset + delta * limit));
+      void show(index, { scroll: true });
+    };
+
+    /* The last page is knowable when the count is: `offset + limit >= total`
+       means there is nothing after this. Without a count — a relationship
+       whose count query failed — a short page is the signal instead. */
+    const more = total === undefined ? data.rows.length === limit : offset + limit < total;
+    const paged = offset > 0 || more;
+
+    panel.replaceChildren(...[
+      el('div', { class: 'record-child-head' }, [
+        el('h3', { text: child.name }),
+        el('span', { class: 'record-child-via', text: `via ${fk.from.columns.join(', ')}` }),
+        // Shown only when there is more than fits, so the control appears
+        // exactly when it is the answer to a question the reader now has.
+        (total ?? data.rows.length) > data.rows.length
+          ? el('button', {
+              type: 'button', class: 'ghost',
+              text: `See all ${total ? total.toLocaleString() : ''} \u2192`.replace('  ', ' '),
+              onclick: openAll,
+            })
+          : null,
+      ].filter(Boolean)),
+      renderGrid(child, data, { onRowClick: (row) => openChild(child, row) }),
+      /* Paging here rather than only through "See all".
+
+         A relationship with ninety-four rows shows ten of them, and the
+         other eighty-four used to be reachable only by leaving the record
+         for a table view — which answers the question in a place that has
+         lost the context the question was asked in. */
+      paged
+        ? el('div', { class: 'child-pager' }, [
+            el('span', {
+              class: 'child-range',
+              text: total
+                ? `${(offset + 1).toLocaleString()}\u2013${Math.min(offset + data.rows.length, total).toLocaleString()} of ${total.toLocaleString()}`
+                : `${(offset + 1).toLocaleString()}\u2013${(offset + data.rows.length).toLocaleString()}`,
+            }),
+            el('button', {
+              type: 'button', class: 'ghost', text: '\u2190 Prev',
+              disabled: offset === 0, onclick: () => turn(-1),
+            }),
+            el('button', {
+              type: 'button', class: 'ghost', text: 'Next \u2192',
+              disabled: !more, onclick: () => turn(1),
+            }),
+          ])
+        : null,
+    ].filter(Boolean));
+
+    /* Chosen from the sidebar, the table you chose should be the thing you
+       are looking at. On a long record the list sits beside the fields and
+       the table it controls is a screen further down, so picking one used to
+       change something off-screen and look like nothing happened.
+
+       Only on an explicit choice — scrolling the page on first render would
+       move a record the reader had not asked to move. */
+    if (scroll) panel.scrollIntoView({ behavior: 'smooth', block: 'start' });
+  };
+
+  /* A table reachable two ways needs two distinguishable tabs. work_order
+     points at itself through parent_id and supersedes_id, and two tabs both
+     reading "work_order" are a coin flip — the distinction only has to be
+     drawn where it exists, so a table appearing once keeps its plain name. */
+  const repeated = new Set(
+    rendered
+      .map((r) => r.child.id)
+      .filter((id, i, all) => all.indexOf(id) !== i),
+  );
+
+  /* How many of these have nothing in them, which is the number worth putting
+     on the control that hides them. On a wide schema most of a record's
+     relationships are empty — eighteen entries, seven of them zero — and the
+     ones with rows are what somebody came to read. */
+  let emptyCount = 0;
+
+  rendered.forEach(({ fk, child, section, data }, index) => {
+    const total = counts.get(fk.name) ?? data.rows.length;
+    const label = section.title
+      ?? (repeated.has(child.id) ? `${child.name} · ${fk.from.columns.join(', ')}` : child.name);
+    const empty = data.rows.length === 0;
+    if (empty) emptyCount += 1;
+    strip.append(el('button', {
+      type: 'button',
+      class: `related-item${empty ? ' empty' : ''}`,
+      role: 'tab',
+      disabled: empty,
+      'aria-selected': String(index === activeIndex),
+      title: `${child.name} via ${fk.from.columns.join(', ')}`,
+      onclick: () => show(index, { scroll: true, chosen: true }),
+    }, [
+      el('span', { class: 'related-count', text: total.toLocaleString() }),
+      el('span', { class: 'related-names' }, [
+        el('span', { class: 'related-table', text: label }),
+        // The relationship, not just the table: work_order appears twice
+        // here, once through parent_id and once through supersedes_id.
+        el('span', { class: 'related-via', text: `via ${fk.from.columns.join(', ')}` }),
+      ]),
+    ]));
+  });
+
+  /* Folded away rather than dropped.
+  
+     An empty relationship is a real answer — "nothing points here through
+     this" is worth being able to check — so it is never removed, only put
+     behind a control that says how many there are. The choice is remembered
+     per connection, because it is about the shape of that database rather
+     than about this record. */
+  const applyEmpty = () => {
+    strip.classList.toggle('hide-empty', hidingEmpty());
+    toggle.textContent = hidingEmpty()
+      ? `show ${emptyCount} empty`
+      : `hide ${emptyCount} empty`;
+    toggle.setAttribute('aria-pressed', String(hidingEmpty()));
+  };
+
+  const toggle = el('button', {
+    type: 'button',
+    class: 'ghost related-empties',
+    title: 'Relationships with no rows',
+    onclick: () => {
+      setHidingEmpty(!hidingEmpty());
+      applyEmpty();
+    },
+  });
+
+  const head = el('div', { class: 'related-head' }, [
+    el('h3', { text: 'Related' }),
+    /* Only when there is something to hide, and only when hiding it leaves
+       something behind: a rail of nothing but empties is better shown than
+       collapsed to a single button explaining that it is empty. */
+    emptyCount && emptyCount < rendered.length ? toggle : null,
+  ].filter(Boolean));
+
+  if (emptyCount && emptyCount < rendered.length) applyEmpty();
+
+  relatedPanel.replaceChildren(head, strip);
+  host.append(panel);
+  void show(activeIndex);
+}
+
+/**
+ * Open a row of an embedded child table.
+ *
+ * The key comes from the row rather than from the section's shown columns,
+ * which is why the key is fetched even when it is hidden.
+ */
+function openChild(child, row) {
+  const key = keyOf(child, row);
+  if (!key) return;
+  go(rowView(child.id, key, rowLabel(child, row)));
+}