Files
sencho/frontend
Anso 03a5826f7e fix(dashboard): debounce state-invalidate refetches (#1209)
* fix(dashboard): debounce state-invalidate refetches and drop redundant listener

useDashboardData fired three immediate HTTP requests (/stats, /system/stats,
/stacks/statuses) for every Docker container event. A burst restart of a
50-container stack produced ~150 instant requests against the local instance
with no throttle. Add a 250 ms trailing-edge debounce so an event storm
collapses into a single coalesced refresh, mirroring the precedent in
useNextAutoUpdateRun. The cleanup function now also clears any pending
debounce timer so a late event cannot fire after the dashboard unmounts.

useConfigurationStatus subscribed to the same event but its data is built
from settings and policy tables (agents, alert rules, auto-heal, scheduled
tasks, scan policies, backup config), none of which change on container
state. Drop the listener entirely; the 60 s poll catches rare settings
edits with acceptable latency.

* fix(dashboard): scope settings-event listener back into useConfigurationStatus

Address two follow-up findings from independent review of the earlier
commit on this branch.

1. Restore a filtered sencho:state-invalidate listener in
   useConfigurationStatus. The earlier commit dropped the listener wholesale
   to keep container-event bursts from refetching settings data, but that
   also silenced the only settings-affecting event in the current taxonomy:
   action='auto-update-settings-changed' (emitted from
   backend/src/routes/stacks.ts when a user toggles a stack's auto-update
   setting). With the listener gone, the Configuration Status row for
   Auto-update stacks could sit stale until the 60 s poll. The new
   listener mirrors the precedent in useNextAutoUpdateRun: filter on the
   single configuration-relevant action, trailing-edge debounce 250 ms.

2. Add an `active` flag to the useDashboardData state-invalidate effect.
   Cleanup already clears the pending debounce timer, but a refresh()
   already in flight could still call setters after unmount because the
   awaited Promise.all has no abort hook. The flag is checked both before
   the await and after, matching the cleanup shape used by
   useNextAutoUpdateRun.

Tests cover both: the configuration listener now ignores scope='stack' and
scope='image-updates' bursts and refetches once on a settings-changed
burst.
2026-05-25 12:13:17 -04:00
..

React + TypeScript + Vite

This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.

Currently, two official plugins are available:

React Compiler

The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see this documentation.

Expanding the ESLint configuration

If you are developing a production application, we recommend updating the configuration to enable type-aware lint rules:

export default defineConfig([
  globalIgnores(['dist']),
  {
    files: ['**/*.{ts,tsx}'],
    extends: [
      // Other configs...

      // Remove tseslint.configs.recommended and replace with this
      tseslint.configs.recommendedTypeChecked,
      // Alternatively, use this for stricter rules
      tseslint.configs.strictTypeChecked,
      // Optionally, add this for stylistic rules
      tseslint.configs.stylisticTypeChecked,

      // Other configs...
    ],
    languageOptions: {
      parserOptions: {
        project: ['./tsconfig.node.json', './tsconfig.app.json'],
        tsconfigRootDir: import.meta.dirname,
      },
      // other options...
    },
  },
])

You can also install eslint-plugin-react-x and eslint-plugin-react-dom for React-specific lint rules:

// eslint.config.js
import reactX from 'eslint-plugin-react-x'
import reactDom from 'eslint-plugin-react-dom'

export default defineConfig([
  globalIgnores(['dist']),
  {
    files: ['**/*.{ts,tsx}'],
    extends: [
      // Other configs...
      // Enable lint rules for React
      reactX.configs['recommended-typescript'],
      // Enable lint rules for React DOM
      reactDom.configs.recommended,
    ],
    languageOptions: {
      parserOptions: {
        project: ['./tsconfig.node.json', './tsconfig.app.json'],
        tsconfigRootDir: import.meta.dirname,
      },
      // other options...
    },
  },
])