Altinity / Altinity/altinity-sql-browser

refactor(shell): the docked inspector's centre minimum is not held between 769px and ~1073px

Aperta
#597 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

inbox refactor
Lingua principale
TypeScript
Stelle
8
Fork
2
Merge medio
1h 34m
PR unite (30g)
6

Descrizione

Surfaced by ChatGPT review pass 2 of PR #596 (#586, phase 1 of #593), verified against the code.
Deliberately not fixed in #586: the remedy is a product decision about what should yield when
the row cannot fit both minima, and this is not a regression against pre-#586 behaviour.

What

clampDockedInspectorWidth (src/ui/splitters.ts:93) computes

const ceiling = Math.min(totalWidth * 0.92, totalWidth - reservedPx - CENTRE_MIN_PX);
return clamp(px, 320, ceiling);

clamp is Math.max(lo, Math.min(hi, v)) (src/core/format.ts:8). So when ceiling < 320, the
inspector's own 320px floor wins and the centre surface absorbs the entire shortfall — the
opposite of what CENTRE_MIN_PX is named for.

The band where this is reachable

The centre only reaches CENTRE_MIN_PX once totalWidth >= reservedPx + 640, where
reservedPx = state.sidebarPx + 2 * HANDLE_PX (src/ui/app-shell.ts:174, HANDLE_PX = 7):

Sidebar width Centre reaches 320px at Unprotected band
248px (default) 902px 769–901px
420px (dragValue's max, splitters.ts:108) 1074px 769–1073px

At 769px with the default sidebar the centre is 187px. 1024px tablet landscape with a widened
sidebar, and half-screen laptop windows, both sit inside this band.

The band starts at 769px because styles.css's full-screen override is
@media (max-width: 768px) — the dock stays active immediately above it.

The comment is wrong, and that is the part to fix regardless of policy

src/ui/splitters.ts:88-91 currently justifies the behaviour:

clamp's own floor (320) wins even when the computed ceiling falls below it (an extremely
narrow window) — that width is styles.css's full-screen mobile override's job
(.inspector-host under MOBILE_BREAKPOINT_PX), not this function's.

That is arithmetically false: the mobile override ends at 768px, while the sub-320 ceiling case
persists up to 901px (1073px with a wide sidebar). Whatever policy is chosen below, this comment
must stop claiming a guarantee the code does not provide.

This is the third comment in #586 to assert behaviour the code lacks (the other two,
state.ts:655 and splitters.ts:36, were fixed in 8539d81). #586's AC6 was specifically about
not leaving future readers a false account of a deliberate decision.

The test cannot catch it either

tests/e2e/inspector-dock-layout.spec.js:125 asserts expect(queryBox.width).toBeGreaterThan(200)
in a test named for protecting the centre surface. 200 is below CENTRE_MIN_PX, so the test
passes at 318px and at 250px alike — it cannot enforce the stated invariant.

Why deferred

Choosing what yields is a product call, and each option has a visible cost:

  1. Let the inspector go below 320px so the centre keeps its minimum — cheapest, but the
    inspector becomes cramped exactly when it is hardest to read.
  2. Raise the full-screen breakpoint to the width at which the dock is actually viable
    (~902px for a default sidebar) — coherent, but changes mobile presentation, which was a #586
    non-goal, and interacts with the deferred modality work in #488.
  3. Auto-fold or narrow the sidebar when the row cannot fit all three — best UX, most work,
    and overlaps #487's left-navigation folding.
  4. Accept a smaller centre and rename/redocument CENTRE_MIN_PX as a soft target.

Option 2 and 3 both touch tracked work (#488, #487), which is why this should not be settled
inside a shell-primitive phase.

Not a regression

Pre-#586 the surface was a position: fixed overlay: at 769px it covered ~707px and obscured the
centre entirely, and no centre minimum existed to violate. This is an incomplete realisation of a
new invariant, not a behaviour that got worse.

Also worth folding in while here

The Math.min(totalWidth * 0.92, …) term is effectively dead: the 92vw side only wins above a
~6425px viewport (it first binds around 8K). No test exercises it, and its comment claims it
"keeps the inspector from claiming more than that even on an otherwise roomy row", which is true
only on an 8K display. Either cover it or drop it.

Acceptance

  • A policy is chosen for the range where totalWidth - reservedPx - CENTRE_MIN_PX < 320, and
    implemented explicitly rather than falling out of clamp with hi < lo.
  • src/ui/splitters.ts:88-91's justification is true of the shipped code.
  • tests/e2e/inspector-dock-layout.spec.js asserts the centre against CENTRE_MIN_PX itself,
    not a weaker literal, with real-browser coverage at 769px, 902px and 1024px, and with
    sidebarPx = 420.
  • The 92vw term is either exercised by a test or removed.
  • npm test, npm run check:types, npm run check:arch, npm run build pass.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia da clampDockedInspectorWidth in src/ui/splitters.ts e dalla copertura del layout in tests/e2e/inspector-dock-layout.spec.js. Leggi le costanti e i commenti correlati in src/ui/app-shell.ts, src/core/format.ts e styles.css, quindi risolvi la policy di prodotto documentata prima di modificare il comportamento. Il lavoro è completato quando la carenza è gestita esplicitamente, la motivazione è corretta, la copertura è presente per le larghezze e le dimensioni della sidebar elencate e i controlli npm test, type, architecture e build hanno esito positivo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
typescript
Ambito
frontend, testing-qa
Tipo di issue
Refactoring
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Tranquilla
Chiarezza
Abbastanza chiara
Idoneità per principianti
35/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.