Files
bambuddy/frontend
maziggy 5033c9c917 fix(backup): don't let SettingsPage revert a restored settings category (#2656)
Restoring App Settings from the Backup tab silently reverted almost everything
    it reported restoring.

    GitHubRestoreModal invalidated ['settings'] on success. SettingsPage — which
    renders the modal — keeps a `localSettings` copy of its form state alongside a
    debounced effect that PATCHes it back whenever the server copy differs. The
    refetch made the two differ, the effect cannot tell "server changed" from "user
    edited", and 500 ms later it wrote the pre-restore values back over the restore.
    75 of the ~80 keys in a backup sit in that save payload, so a restore reporting
    "77 restored, 0 failed" left only the five auth/internal flags behind. The
    backend was correct throughout: the same restore driven against the API with no
    browser open applies cleanly.

    Since the Restore button lives on the Settings page, this was the default path
    rather than an edge case.

    Fixed inside the modal rather than in SettingsPage: that debounce's own comments
    show it was tuned to avoid resetting text fields mid-typing, and widening this
    change into it risks that. So ['settings'] is no longer invalidated, and every
    exit path (footer Close, header X, overlay click, Escape) now reloads instead of
    closing when settings were among the restored categories, since leaving the page
    mounted is what arms the overwrite. The ['spools'] and ['archives']
    invalidations are unchanged — SettingsPage is the only page carrying this kind
    of whole-payload auto-save.

    The root cause is left for a follow-up: any future feature that writes settings
    server-side will be reverted the same way.

    Found by manual end-to-end testing against a private test repo, which also
    confirmed the natural-key id remapping and the overwrite-off behaviour working
    as designed.
2026-08-15 14:10:34 +02: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...
    },
  },
])