feat(web): allow resizing the file explorer#25737

merged1
main
maria/takeover-pr-25242
opened2d agobyMmaria
View on GitHubTwo-way sync enabledPR last imported 1h ago

Problem

The file explorer beside an open file has a fixed width, so long paths remain truncated even when the outer panel is widened.

Change

Reuse the existing resize handle and drag hook for a saved explorer width, with keyboard resizing and container-aware bounds. Keep the existing show/hide controls and full-width explorer-only layout. Measure through a ref callback, removing the original effect and lint suppression. Web and desktop share this component; no server, provider, contract, or mobile changes are needed.

Scope and approval

Addresses issue #11559 and follows @juliusmarminge's suggested fix: add an inner handle, persist width, and clamp to the current panel. Scope is limited to the existing file explorer. The 256px default and new resizing interaction remain subject to Maria's review.

Verification

  • Passed on Blacksmith: vp run check:changed (format, lint, both knip checks, affected typechecks, 33 existing file-preview tests).
  • Passed on Blacksmith: React Compiler coverage, 1,250 cases.
  • System Chrome against the real dev app: main's boundary stayed at 352px after dragging; replacement drags between 256px and 496px. Keyboard arrows and Home/End, saved width after hide/show and reload, outer-panel clamping to 283px and restoration, blocked storage, unmount during drag, and the explorer-only layout passed. Checked light/dark and a 1000px viewport.
  • Unverified: native desktop packaging, mobile (separate UI), and remote/tunnel connections. Uploaded video playback and seeking were checked in Chrome.
  • No new test files. The original standalone browser test file was omitted under this task's constraint; its scenarios were exercised directly in the app.

Evidence

before: fixed 352px explorer on main

after: explorer widened to 496px

drag resizing and hide/show restore the saved width

Takeover

Replaces #25242, with thanks to @07rjain for the original implementation.

Built with GPT-6.1-Sol in the Codex harness on T3 Code.

Checks

24 successful · 16 skipped · 1 neutral
All checks passed
0a87f74

Added 1 commit

  • feat(web): allow resizing the file explorer0a87f74
Synced from GitHub

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — This PR adds persisted drag and keyboard resizing for the file explorer and changes its default width from the existing 22rem-based layout to 256px. The product-default change and new interactive behavior warrant human review.

You can add or adjust custom eligibility rules. Learn more.

Synced from GitHub

Review in Change Stack →

No actionable comments were generated in the recent review.

External image Recent review info
External image Run configuration
External image Commits

Reviewing files that changed from the base of the PR and between 5127de8c29ede39fc567337cebc4726fbaa16b63 and 0a87f746e41248531bc523e6dec2c710ee231488.

External image Files selected for processing: 4
  • apps/web/src/components/files/FileExplorerPane.tsx
  • apps/web/src/components/files/FilePreviewPanel.tsx
  • apps/web/src/components/preview/RightPanelResizeHandle.tsx
  • apps/web/src/hooks/useResizableWidth.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 2 remain after this review.

Walkthrough

The file explorer pane can resize when a preview is active. It uses persisted, bounded widths and supports pointer and keyboard input. The shared resize hook exposes direct width updates, and the resize handle forwards accessibility and keyboard properties.

Changes: File Explorer Resizing

Layer / File(s)Summary
Shared resize APIs
apps/web/src/hooks/useResizableWidth.ts, apps/web/src/components/preview/RightPanelResizeHandle.tsx
The hook adds a clamped setWidth method and uses shared logic for state updates and persistence. The resize handle forwards selected div properties and an optional accessibility label. Its focus-visible indicator uses the primary color at 60% opacity.
Explorer pane and preview integration
apps/web/src/components/files/FileExplorerPane.tsx, apps/web/src/components/files/FilePreviewPanel.tsx
FileExplorerPane adds persisted sizing, width bounds, and pointer and keyboard resizing. FilePreviewPanel uses the pane and enables resizing when previewPath is truthy.

Priority: External image Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Feature

Sequence Diagram(s)

mermaid
1sequenceDiagram
2 participant FilePreviewPanel
3 participant FileExplorerPane
4 participant useResizableWidth
5 participant RightPanelResizeHandle
6 FilePreviewPanel->>FileExplorerPane: Render with resizable based on previewPath
7 FileExplorerPane->>useResizableWidth: Read and update persisted width
8 FileExplorerPane->>RightPanelResizeHandle: Render resize handle with handlers
9 RightPanelResizeHandle->>FileExplorerPane: Forward pointer or keyboard input
10 FileExplorerPane->>useResizableWidth: Commit clamped width

Possibly related PRs

Suggested labels: takeover, vouch:unvouched, size:M

Suggested reviewers: juliusmarminge

Merge Risk: External image Minimal · up to 0a87f

The explorer resizing change is mergeable subject to normal checks; no concrete blocking issue has been established.

Pre-merge checks: Passed 4
Check nameStatusExplanation
Title checkPassedThe title clearly and concisely describes the primary change: adding file explorer resizing in the web application.
Linked Issues checkPassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes checkPassedCheck skipped because no linked issues were found for this pull request.
Description checkPassedThe description follows the template's main sections (Problem, Change, Scope and approval, Verification) and is detailed. It explains the problem (fixed-width file explorer truncates long paths), the …
Full details: Description check

Explanation

The description follows the template's main sections (Problem, Change, Scope and approval, Verification) and is detailed. It explains the problem (fixed-width file explorer truncates long paths), the change (saved width, keyboard resizing, container-aware bounds, ref callback replacing an effect), and the scope (linked issue #11559 and a maintainer-suggested fix). Verification lists the commands run, Chrome checks, and what was not verified, and includes before/after screenshots. The template's Scope section asks for a maintainer approval comment. The author links a suggested-fix comment from a maintainer, but the description does not clearly show explicit approval of this direction. The description also says the 256px default and interaction remain subject to a named reviewer's review, which signals that approval is still open. The template's title guidance is a conventional commit title, and the PR title is not in the provided context. The template's trailing agent-model line is present.

Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Comment @coderabbitai help to get the list of available commands.

Synced from GitHub

For CodeRabbit’s description warning, the scope reference from the original PR is issue #11559 and Julius’s suggested fix: add a left-edge explorer handle, persist its width, and clamp it against sensible bounds and the current panel width. This replacement remains scoped to that explorer; diff/PR trees are outside the change.

These references can be carried into the replacement description’s “Scope and approval” section. The suggested implementation is prior maintainer guidance; it does not replace the human approval requested by Macroscope for this PR.

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified as-is at 0a87f746e41248531bc523e6dec2c710ee231488 on this linux boat vm. no code changes or pushes.

  • installed with vp i on github/main (07f7f97609) in a separate worktree and on the exact pr head. ran one background dev server at a time, with isolated state and system chrome driven by the repository's playwright.
  • created the project and threads through the app. real codex gpt-6.1-sol turns created the two files on main (17s), then read and verified them on the pr (19s). opened the provider's file link into the actual file preview.
  • reproduced main: a 200px left-edge drag left the explorer at 352px and the long filename truncated. on the pr, dragging widened it from 256px to 496px and exposed the full filename.
  • passed keyboard arrows (16px), Home (160px), End (560px), accessible width values, hide/show and reload persistence, outer-panel clamping (283px) and restoration (496px).
  • nearby behavior passed: file switching and content loading, rendered markdown, full-width explorer-only view with no divider, return to file preview, and the existing outer-panel pointer resize (140px). checked light/dark and a 1000px viewport. no browser page errors.
  • inspected the screenshots and recording. uploaded video playback and seeking passed in t3's browser.

short runtime transcript

before on main: fixed 352px explorer with truncated filename

after on pr: explorer widened to 496px with the full filename visible

real app: drag, hide/show, outer-panel bounds, keyboard resizing and file navigation

Not verified

native desktop packaging or macos/windows behavior, native ios/android, remote/relay/tunnel connections, other providers, and assistive-technology narration were not exercised on this linux web-client pass. web and desktop share the changed component; mobile is separate.

no new checks were run because no source changes were needed. github currently reports 25 successful, 15 skipped, 1 neutral and 1 cancelled context (Native fingerprint diff), with no failing or pending contexts. cafe reports 34/34 successful checks. these ci results are separate from the runtime proof above.