23 lines
1.8 KiB
Markdown
23 lines
1.8 KiB
Markdown
# 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). |