1.8 KiB
Research: Frontend Navigation Redesign
Decisions
1. Backup Management UI Strategy
Decision: Create a dedicated BackupManager component in frontend/src/components/backups/.
Rationale: The requirement is to have a "full component" accessible from the dashboard. Separating it into its own directory ensures modularity and keeps the Dashboard component clean. It will consume the existing backup APIs (likely /api/tasks with specific backup types or a dedicated backup endpoint if one exists - to be verified in Phase 1).
Alternatives considered: Embedding backup controls directly in the Dashboard (rejected: clutters the main view), reusing the TaskRunner component (rejected: need specific backup context/history view).
2. Navigation State Management
Decision: Use SvelteKit's layout system (+layout.svelte) and simple component props for Navbar state.
Rationale: The Navbar changes are global. Removing items is a static change to the Navbar.svelte component. No complex state management (stores) is needed for this structural change.
Alternatives considered: Dynamic config-based menu (rejected: overkill for this specific redesign).
3. Deprecation Strategy
Decision: Hard removal of "Dataset Search" and "Deployment Environments" components and routes. Rationale: The spec explicitly calls for removal. Keeping dead code increases maintenance burden. Alternatives considered: Hiding behind a feature flag (rejected: requirement is explicit removal).
4. Dashboard Grid Layout
Decision: Update DashboardGrid.svelte to include new cards for Mapper, Storage, and Backups.
Rationale: Reusing the existing grid component maintains consistency.
Alternatives considered: Creating a separate "Tools" page (rejected: spec requires access from main Dashboard).