Files
ServerKit/frontend
Juan DenisandClaude Opus 5 f21abe7af5 feat(ui): one visibility-aware polling convention, and a ratchet on the rest
Plan 76 milestone E2, drift/bug row 4. 45 hand-rolled setInterval sites across
35 files, with `visibilitychange` handled in exactly one of them and an
in-flight guard in exactly one of them — the documented poller-stampede shape.

Two failures every hand-rolled `setInterval(load, 5000)` shares:

- it starts a request every 5s whether or not the previous one returned. A slow
  endpoint does not slow the poller down, it makes it stack; each extra request
  makes the server slower, which makes the next overlap more likely. This is
  what a DevTools capture of /domains showed as a wall of pending rows.
- it keeps polling a tab nobody is looking at, where browsers throttle timers
  unevenly anyway, so it is not even a reliable refresh.

utils/pollScheduler.js holds the rules as a plain object so they are testable
without a DOM (the repo has no jsdom — this follows formState.js/useForm).
hooks/usePolling.js is the React binding, and useServerQuery gains
`refetchInterval` built on the same scheduler, so there is one implementation
rather than a second one for query users.

Two design points worth stating, since both differ from what the sites did:

- the next tick is armed by the previous run *finishing*, not by setInterval.
  With setInterval the gap is measured tick-to-tick regardless of how long the
  work took, so slow work silently turns a 5s gap into no gap. The in-flight
  guard therefore protects the out-of-band paths — refresh() and the visibility
  catch-up — rather than the schedule, and the test says so instead of implying
  a guard the schedule can no longer exercise.
- the callback is held in a ref, so an inline arrow re-created each render does
  not restart the timer. That is the usual reason a hand-rolled poller runs far
  faster than its stated interval.

Migrated four as reference implementations, per the plan's "migrate a
representative flow before broader adoption": DeployPill (which had worked all
of this out by hand and loses ~20 lines), MonitorsSummary, appdetail/LogsTab,
and ProcessListPanel. MonitorsSummary keeps its `refreshKey` prop as an explicit
out-of-band refresh rather than folding it into the schedule.

Ratchet: check-frontend-boundaries.mjs gains LEGACY_POLLERS with exact per-file
counts, now 41 sites in 31 files, so every future cleanup must shrink it and a
new bare setInterval fails lint. Genuine non-fetching timers (clock ticks,
countdowns) are listed too rather than pattern-matched away — they are harmless
but the exact count is what makes the ratchet trustworthy.

Gate: npm test (72 passed, 11 of them new), npm run lint (0 errors; 954
warnings, one fewer than the 955 baseline), npm run build clean, boundary check
green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-18 20:45:59 -04:00
..

React Dashboard Template

A modern React dashboard application boilerplate built with Vite, featuring routing, charts, and a sidebar layout for building data-driven web interfaces.

Features

  • React 18 with functional components and hooks
  • Vite for fast development and building
  • React Router for client-side routing
  • Recharts for data visualization
  • Lucide React for icons
  • ESLint for code linting
  • Responsive sidebar layout
  • Dashboard page with sample components

Getting Started

Prerequisites

  • Node.js 16+ and npm

Installation

  1. Clone or download this template
  2. Install dependencies:
npm install

Development

Start the development server:

npm run dev

The app will be available at http://localhost:41921.

Building for Production

Build the app for deployment:

npm run build

The output will be in the dist/ directory.

Preview Production Build

npm run preview

Project Structure

src/
├── App.jsx              # Main app with routing
├── main.jsx             # Entry point
├── index.css            # Global styles
├── components/
│   └── Sidebar.jsx      # Navigation sidebar
├── layouts/
│   └── DashboardLayout.jsx  # Main layout wrapper
└── pages/
    └── Dashboard.jsx    # Main dashboard page

Customization

  • Modify components in src/components/
  • Add new pages in src/pages/
  • Update routes in App.jsx
  • Customize styles in index.css or component files

Environment Variables

Create a .env file in the root for environment variables:

VITE_API_URL=https://api.example.com

Access them in code via import.meta.env.VITE_API_URL.

Contributing

See the documentation files for AI agent permissions and guidelines.