improve(pages): simplify ErrorBoundary reload UX and add unit tests

[lizhengfeng101]

Description

The ErrorBoundary component introduced in #542 handles stale lazy-loaded chunks gracefully. Two follow-up improvements would make it more robust and maintainable:

1. Simplify the Reload button interaction

Currently, when the user clicks the "Reload" button in RouteErrorFallback, the reset() method clears the sessionStorage guard and resets the React error state. This causes the lazy import to re-attempt → fail → trigger componentDidCatch → auto-reload the page (since the guard was cleared). The user ends up waiting through an indirect reload cycle.

A simpler approach: have the Reload button call window.location.reload() directly (after clearing the session guard), making the behavior transparent and predictable.

// Current (indirect)
private reset = (): void => {
  try { window.sessionStorage.removeItem(CHUNK_RELOAD_STORAGE_KEY); } catch {}
  this.setState({ error: null });
};

// Proposed (direct)
private reset = (): void => {
  try { window.sessionStorage.removeItem(CHUNK_RELOAD_STORAGE_KEY); } catch {}
  window.location.reload();
};

2. Add unit tests for ErrorBoundary

The component has no test coverage. Key scenarios to cover:

• A chunk load error triggers window.location.reload()
• The sessionStorage guard prevents a second automatic reload
• Non-chunk errors display the fallback without reloading
• reset() clears the guard and retries correctly

Scope

• File(s): pages/src/components/ErrorBoundary.tsx, pages/src/App.tsx
• New test file: pages/src/components/ErrorBoundary.test.tsx

Acceptance Criteria

• Reload button triggers a direct page reload instead of the indirect reset-and-catch cycle
• Unit tests cover the four scenarios listed above
• npm run typecheck passes from pages/
• npm run build passes from pages/

Context

Discovered during review of #542. The current implementation is functional and safe — this is a polish pass to improve UX clarity and ensure long-term maintainability of a critical error-handling component.

[wangqiao258]

Hi @lizhengfeng101, I'd like to take this.

Plan:

1. Change RouteErrorFallback's Reload button to call window.location.reload() directly after clearing the session guard (replacing the indirect reset-and-catch cycle).
2. Add unit tests in pages/src/components/ErrorBoundary.test.tsx covering the four scenarios listed in the issue.

One heads-up: pages/package.json currently has no test runner. I'd suggest adding vitest + @testing-library/react + jsdom (vitest works standalone alongside the existing webpack/babel toolchain). Would you be OK with this, or do you prefer another framework? I'll proceed with vitest unless you say otherwise.

I'll verify npm run typecheck and npm run build from pages/. Could you assign it to me?

[lizhengfeng101]

Hi @lizhengfeng101, I'd like to take this.

Plan:

1. Change RouteErrorFallback's Reload button to call window.location.reload() directly after clearing the session guard (replacing the indirect reset-and-catch cycle).
2. Add unit tests in pages/src/components/ErrorBoundary.test.tsx covering the four scenarios listed in the issue.

One heads-up: pages/package.json currently has no test runner. I'd suggest adding vitest + @testing-library/react + jsdom (vitest works standalone alongside the existing webpack/babel toolchain). Would you be OK with this, or do you prefer another framework? I'll proceed with vitest unless you say otherwise.

I'll verify npm run typecheck and npm run build from pages/. Could you assign it to me?

ok assigned