Altinity / Altinity/altinity-sql-browser

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

Open
#597 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

inbox refactor
Dominant language
TypeScript
Stars
8
Forks
2
Avg merge
1h 34m
Merged PRs (30d)
6

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with clampDockedInspectorWidth in src/ui/splitters.ts and the layout coverage in tests/e2e/inspector-dock-layout.spec.js. Read the related constants and comments in src/ui/app-shell.ts, src/core/format.ts, and styles.css, then resolve the documented product policy before changing behavior. Done means explicit handling of the shortfall, corrected justification, coverage at the listed widths and sidebar sizes, and passing npm test, type, architecture, and build checks.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, testing-qa
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.