mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-10-01 11:47:46 +02:00
jmoore-skild
208170b03a
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. Tests: 3 new frontend tests — the settings query is never invalidated, a settings restore reloads rather than closing, and a non-settings restore still closes normally. The first two fail against the pre-fix component. Full frontend suite green (186 files / 2459 tests), i18n parity unchanged, eslint clean.
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:
- @vitejs/plugin-react uses Babel (or oxc when used in rolldown-vite) for Fast Refresh
- @vitejs/plugin-react-swc uses SWC for Fast Refresh
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...
},
},
])