Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

refactor(shell): a live sidebar drag leaves the docked inspector's width stale

Offen
  • Stimmt etwas nicht?
#598 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Ruhig
Tech-Stack
typescript
Bereich
frontend, testing-qa

Rechercherichtung

Beginne in src/ui/app-shell.ts bei dragCtx.apply und der vorhandenen Reclamp-Logik des Inspectors und untersuche dann src/ui/splitters.ts sowie die vorhandenen Sidebar-Tests. Führe zuerst den relevanten Browser-Test aus und füge Abdeckung für das Ziehen von .col-resize hinzu, während der Inspector geöffnet bleibt. Erledigt ist die Aufgabe, wenn die Mitte CENTRE_MIN_PX einhält, die gespeicherte Einstellung rightInspectorPx unverändert bleibt und alle aufgeführten npm-Prüfungen bestehen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

inbox refactor

Surfaced by ChatGPT review pass 2 of PR #596 (#586, phase 1 of #593), verified against the code.
Deliberately not fixed in #586 — see "Why deferred".

What

#586 made the docked inspector's displayed width dock-aware: its ceiling reserves
CENTRE_MIN_PX for the centre surface plus reservedPx = state.sidebarPx + 2 * HANDLE_PX
(src/ui/app-shell.ts:174). The re-clamp (app.dom.reclampInspectorWidth) runs at three moments:

  1. shell construction (app-shell.ts:252),
  2. inspector unfold (called from showInInspector),
  3. window resize.

A live left-sidebar drag is not one of them. dragCtx.apply (src/ui/app-shell.ts:182-186)
handles the 'col' axis by setting sidebar.style.width only:

apply: (axis, value) => {
  if (axis === 'col') sidebar.style.width = value + 'px';
  else if (axis === 'rightInspector') inspectorHost.style.width = value + 'px';
  else schemaPane.style.height = value + '%';
},

So while both panels are visible, widening the sidebar silently invalidates the reservation the
inspector's width was chosen against.

Reproduction

At a 1280px viewport:

  1. Open Cell, Rows or Reference and size the inspector to 600px (default sidebar 248px →
    reservedPx 262 → centre ≈ 418px).
  2. Drag .col-resize to the sidebar's maximum 420px (dragValue's clamp(ev.clientX, 180, 420),
    src/ui/splitters.ts:108) → reservedPx becomes 434.
  3. The inspector stays 600px, so the centre falls to ≈ 246px — below CENTRE_MIN_PX (320) — and
    stays there until an unrelated window resize or a fold/unfold happens to re-clamp it.

Why the existing tests miss it

Both new tests avoid the live transition:

  • the e2e sidebar test closes the inspector, changes the sidebar, then reopens it (so the unfold
    hook does the work);
  • the unit test changes state.sidebarPx while the inspector is folded.

Neither drags the sidebar while the inspector is open, which is the only path that exposes this.

Why deferred

It is a small, self-contained fix, but it shares a root cause with the centre-minimum policy
question (filed separately): both are about what the shell does when the row's three columns
cannot all keep their minima. Fixing the re-clamp alone would keep the centre at
CENTRE_MIN_PX only while that is feasible, so the two are best resolved together. It is also
not a regression — pre-#586 the surface was a position: fixed overlay that the sidebar's width
did not interact with at all.

Acceptance

  • The 'col' apply path re-clamps the displayed inspector width, without mutating the
    saved rightInspectorPx preference (the same displayed-vs-preferred split #586 established).
  • A real-browser test drags .col-resize while the inspector stays open and asserts the
    centre against CENTRE_MIN_PX. happy-dom evaluates no CSS layout, so a unit test cannot
    stand in for this.
  • npm test, npm run check:types, npm run check:arch, npm run build pass.
Vorherrschende Sprache
TypeScript
Sterne
8
Forks
2
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Altinity/altinity-sql-browser

Alle Issues in Altinity/altinity-sql-browser

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.