[WIP] Optimize resize handler in usePaneWidth.ts for better window resize performance

[Copilot]

Optimize PageLayout Pane Resize Handler Implementation

Completed:

• Create usePaneWidth.ts hook to extract pane width logic from PageLayout component
• Implement window resize handler using requestAnimationFrame instead of throttle
• Keep visual clamping (CSS variable updates) immediate to prevent overflow
• Defer ARIA attribute and React state updates using requestIdleCallback with fallback
• Update VerticalDivider in PageLayout.tsx to use the new hook
• Add tests for usePaneWidth resize behavior
• Update PageLayout snapshots with new CSS property
• Run full test suite to validate changes
• Run linting and formatting
• Perform code review
• Run security scanning

Original prompt

Problem

The current implementation of usePaneWidth.ts in the PageLayout component uses a 100ms throttle for window resize events, which can cause perceptible delays during rapid window resizing. Additionally, React state updates during resize can trigger unnecessary re-renders.

Background

This is a follow-up optimization to PR #7307 which introduced performance improvements for PageLayout pane dragging. The resize handler implementation could be further optimized to reduce thread blocking.

Current Issues

1. 100ms throttle delay: Updates to ARIA values and max width clamping happen at most every 100ms during rapid window resizing, causing brief visual lag.

2. State updates during resize: The code updates React state (setMaxPaneWidth, potentially setCurrentWidth) during resize, which triggers re-renders that aren't strictly necessary for visual updates.

3. Not aligned with browser paint cycle: The throttle uses arbitrary time intervals rather than aligning with requestAnimationFrame.

Proposed Solution

1. Replace throttle with requestAnimationFrame: Align resize updates with the browser's paint cycle for smoother visual updates:

let rafId: number | null = null
const handleResize = () => {
  if (rafId !== null) return
  rafId = requestAnimationFrame(() => {
    updateMax()
    rafId = null
  })
}

2. Defer non-critical updates: ARIA attribute updates and React state updates don't need to be synchronous during active resizing. Consider using requestIdleCallback (with fallback) for these updates while keeping visual clamping immediate.

3. Keep visual updates immediate: The CSS variable update for pane width clamping should remain synchronous to prevent visual overflow during resize.

Files to Modify

• packages/react/src/PageLayout/usePaneWidth.ts - Update the resize handler implementation

Acceptance Criteria

• Resize handler uses requestAnimationFrame instead of/in addition to throttling
• Visual pane width clamping remains immediate (no overflow during resize)
• ARIA/state updates are deferred to reduce main thread blocking
• Existing tests continue to pass
• No regressions in resize behavior

This pull request was created as a result of the following prompt from Copilot chat.

Problem

The current implementation of usePaneWidth.ts in the PageLayout component uses a 100ms throttle for window resize events, which can cause perceptible delays during rapid window resizing. Additionally, React state updates during resize can trigger unnecessary re-renders.

Background

This is a follow-up optimization to PR #7307 which introduced performance improvements for PageLayout pane dragging. The resize handler implementation could be further optimized to reduce thread blocking.

Current Issues

1. 100ms throttle delay: Updates to ARIA values and max width clamping happen at most every 100ms during rapid window resizing, causing brief visual lag.

2. State updates during resize: The code updates React state (setMaxPaneWidth, potentially setCurrentWidth) during resize, which triggers re-renders that aren't strictly necessary for visual updates.

3. Not aligned with browser paint cycle: The throttle uses arbitrary time intervals rather than aligning with requestAnimationFrame.

Proposed Solution

1. Replace throttle with requestAnimationFrame: Align resize updates with the browser's paint cycle for smoother visual updates:

let rafId: number | null = null
const handleResize = () => {
  if (rafId !== null) return
  rafId = requestAnimationFrame(() => {
    updateMax()
    rafId = null
  })
}

2. Defer non-critical updates: ARIA attribute updates and React state updates don't need to be synchronous during active resizing. Consider using requestIdleCallback (with fallback) for these updates while keeping visual clamping immediate.

3. Keep visual updates immediate: The CSS variable update for pane width clamping should remain synchronous to prevent visual overflow during resize.

Files to Modify

• packages/react/src/PageLayout/usePaneWidth.ts - Update the resize handler implementation

Acceptance Criteria

• Resize handler uses requestAnimationFrame instead of/in addition to throttling
• Visual pane width clamping remains immediate (no overflow during resize)
• ARIA/state updates are deferred to reduce main thread blocking
• Existing tests continue to pass
• No regressions in resize behavior

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[changeset-bot]

⚠️ No Changeset found

Latest commit: dea3b28

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR