refactor(shell): the docked inspector's centre minimum is not held between 769px and ~1073px
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- リファクタリング
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- typescript
- 領域
- frontend, testing-qa
調査の方向性
src/ui/splitters.ts の clampDockedInspectorWidth と、tests/e2e/inspector-dock-layout.spec.js のレイアウトカバレッジから始めます。src/ui/app-shell.ts、src/core/format.ts、styles.css にある関連する定数とコメントを読み、その後、動作を変更する前に文書化されたプロダクトポリシーを確定します。完了条件は、不足分が明示的に処理され、根拠が修正され、記載された幅とサイドバーサイズがカバレッジされ、npm test、type、architecture、build のチェックに合格することです。
索引モデルが issue の本文から書いたものです。
説明
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 isstyles.css's full-screen mobile override's job
(.inspector-hostunderMOBILE_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:
- 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. - 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. - Auto-fold or narrow the sidebar when the row cannot fit all three — best UX, most work,
and overlaps #487's left-navigation folding. - Accept a smaller centre and rename/redocument
CENTRE_MIN_PXas 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 ofclampwithhi < lo. -
src/ui/splitters.ts:88-91's justification is true of the shipped code. -
tests/e2e/inspector-dock-layout.spec.jsasserts the centre againstCENTRE_MIN_PXitself,
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 buildpass.
- 主要言語
- TypeScript
- スター
- 8
- フォーク
- 2
- 平均マージ
- 1時間 34分
- マージ済み PR(30日)
- 6
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
Altinity/altinity-sql-browser のほかの issue
-
inbox
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
Altinity/altinity-sql-browser#605 ·
-
inbox
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
Altinity/altinity-sql-browser#509 ·
-
inbox
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
Altinity/altinity-sql-browser#489 ·
-
flamegraph オープンenhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
Altinity/altinity-sql-browser#684 ·
-
bug
難易度 4/5 3〜5日 初心者へのやさしさ 68/100
Altinity/altinity-sql-browser#680 · コメント 2 件 ·
Altinity/altinity-sql-browser の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
area:tools bug good first issue help wanted priority:P2
難易度 2/5 1〜3時間 初心者へのやさしさ 90/100
TaewoooPark/Motifcode#14 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
newrelic-experimental/preflight#793 · コメント 1 件 ·
-
bug 🐞
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
[Bounty proposal] fix(web): memory insights count an evening memory on the next day ($25 proposed) オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
BasedHardware/omi#15320 ·