147 lines
8.9 KiB
Markdown
147 lines
8.9 KiB
Markdown
# Redis GUI Desktop Workspace Baseline
|
|
|
|
Date: 2026-03-27
|
|
Owner: Senior Frontend Engineer
|
|
Related issues: HAC-8, HAC-9, HAC-10, HAC-11
|
|
|
|
## Current Assessment
|
|
|
|
- The repository already had a valid desktop entry at `apps/desktop` and a working Tauri bridge for `backend_bootstrap`.
|
|
- The repository also already exposed stable desktop commands for connection testing and command execution through `test_redis_connection` and `execute_redis_command`.
|
|
- The previous frontend surface was only a minimal Vite JavaScript shell and did not match the target implementation stack for downstream UI work.
|
|
- The first frontend milestone therefore needed a visible React workspace before feature delivery could continue efficiently.
|
|
|
|
## Recommended V1 UI Scope
|
|
|
|
The first visible product surface should include:
|
|
|
|
- a stable desktop shell with a persistent connection context
|
|
- a connection library and a new-connection entry point
|
|
- a database switcher that keeps the current DB visible
|
|
- a key browser with search and selection states
|
|
- a value inspector with string-edit support and explicit read-only states
|
|
- a scoped command tray that makes connection and DB context obvious
|
|
- destructive-action confirmation that repeats the key name and DB
|
|
|
|
The first visible product surface should not include:
|
|
|
|
- cluster topology
|
|
- metrics dashboards
|
|
- bulk actions
|
|
- multi-connection comparison
|
|
- full editing support for every Redis type
|
|
- privileged administrative commands
|
|
|
|
## Information Architecture
|
|
|
|
Use a four-zone workspace:
|
|
|
|
1. Utility rail
|
|
2. Browser pane
|
|
3. Inspector pane
|
|
4. Command tray
|
|
|
|
### Utility rail
|
|
|
|
- Connection library
|
|
- New connection form entry point
|
|
- Active DB switcher
|
|
- Safety posture and backend boundary summary
|
|
- Local smoke fixture assist for repeatable QA runs
|
|
|
|
### Browser pane
|
|
|
|
- Search or key pattern filter
|
|
- Result count summary
|
|
- Compact key rows with type and TTL
|
|
- Empty state when no keys match
|
|
|
|
### Inspector pane
|
|
|
|
- Selected key header
|
|
- Value surface
|
|
- Save action for string keys only
|
|
- TTL control for set and persist flows
|
|
- Explicit read-only treatment for unsupported types
|
|
- Metadata and support note beside the edited surface
|
|
|
|
### Command tray
|
|
|
|
- Scoped command input
|
|
- Visible connection and DB scope
|
|
- Result history
|
|
- Hard block for destructive or administrative commands
|
|
|
|
## Visual Direction
|
|
|
|
- Calm and editorial rather than dashboard-like
|
|
- Dense enough for operator workflows without visual noise
|
|
- Structure driven by typography, separators, and restrained tinted surfaces
|
|
- Strong emphasis only for selection, state, or destructive intent
|
|
- Support both light and dark modes with low-noise neutral palettes
|
|
|
|
## Implementation Baseline Added On 2026-03-27
|
|
|
|
- `apps/desktop` now runs on React and Tailwind-based styling.
|
|
- The shell now consumes the existing Tauri bridge for `backend_bootstrap`, `test_redis_connection`, `browse_redis_keys`, `read_redis_value`, `write_redis_value`, and `execute_redis_command`.
|
|
- The inspector now consumes `update_redis_key_ttl` for live TTL set and persist actions in desktop runtime.
|
|
- The repository now also contains a visible string-only `Add key` dialog wired to `create_redis_value`, but that capability remains a separately tracked next-phase surface rather than part of this baseline milestone's required acceptance.
|
|
- shadcn-style UI primitives are used locally for buttons, inputs, textareas, badges, and dialogs.
|
|
- Browser-only dev mode uses explicit demo fallback so the visible shell can still be reviewed without a Tauri runtime.
|
|
- Tauri desktop mode now allows live connection tests, live key browsing, live value inspection, string save for supported keys, live TTL updates, and live command execution while keeping browser dev mode on explicit demo fallback.
|
|
- Non-string live values now render in structured read-only panels for `hash`, `list`, `set`, `zset`, and `stream`, so operators can scan typed payloads without reading raw JSON dumps.
|
|
- The visible shell now validates draft-connection name, host, port, and DB input before creation, and prevents duplicate profile names inside the local shell state.
|
|
- The DB switcher now exposes a predictable default operator range from `db0` through `db15` and keeps an out-of-range active DB visible instead of depending on a four-item hardcoded list.
|
|
- Zero-result key searches now place the inspector into an explicit empty state instead of leaving a stale key visible.
|
|
- Frontend error handling now routes stable backend error codes through a shared operator-facing notice layer so live failures render with consistent copy and banner tone across connection, browse, inspect, write, TTL, and command flows.
|
|
- The inspector now also renders a dedicated readability layer with explicit inspect status, value-surface semantics, next-step guidance, and key facts so string, structured, missing, and demo-fallback states are easier to interpret.
|
|
- Current-phase writable actions now require a scoped review step before string save, TTL set, or TTL removal proceeds, and no-op submissions are blocked before they reach the live bridge or demo fallback.
|
|
- The utility rail now exposes a bounded local smoke assist surface with fixture targeting, `smoke:*` focus, safe command presets, and the seeded key list from the local smoke runbook.
|
|
- Browser-only demo mode now keeps session-local mock string-save and TTL changes visible in the browser, inspector, and mock command responses so shell review does not claim success while leaving stale UI state behind.
|
|
|
|
## QA Acceptance For This Milestone
|
|
|
|
- The shell renders four distinct zones: rail, browser, inspector, command tray.
|
|
- The header keeps app version, runtime mode, and build mode visible for smoke validation.
|
|
- The utility rail exposes a copyable QA snapshot with runtime, connection, selection, and latest command context.
|
|
- The utility rail exposes the seeded local smoke fixture path and safe smoke shortcuts without requiring manual re-entry from the runbook.
|
|
- The active connection and active DB stay visible without opening a modal.
|
|
- The DB switcher exposes `db0` through `db15` by default and still keeps the current DB visible when the active scope falls outside that range.
|
|
- Search filters the browser list and shows a no-results state.
|
|
- Search now exposes explicit mode feedback so operators can see whether the current input is being treated as a contains search or a raw Redis pattern.
|
|
- Search now exposes a bounded clear action in the browser header so operators can return to normal browse state without manually deleting the entire input.
|
|
- When search returns zero keys, the inspector switches to an empty state instead of showing the last selected key.
|
|
- Empty browser and inspector states now distinguish between an empty DB and a filtered no-match result instead of using one generic no-results sentence.
|
|
- The connection action distinguishes desktop live testing from browser demo fallback.
|
|
- Invalid draft connections cannot be created from the visible shell.
|
|
- Live backend failures are shown through a consistent banner treatment instead of per-surface ad hoc copy.
|
|
- Non-string keys are explicitly read-only.
|
|
- Non-string keys render as structured typed panels instead of raw JSON text blobs.
|
|
- The inspector keeps current status, value semantics, action guidance, and key facts visible without requiring operators to infer meaning from badges or raw payload shape alone.
|
|
- String keys show a save affordance near the value surface.
|
|
- TTL controls stay beside the inspector metadata and expose both set and remove flows.
|
|
- String save and TTL mutations now require a second review step that repeats scoped current-vs-next state before continuing.
|
|
- Failed save and TTL attempts keep the current draft value or TTL input in place so operators can adjust and retry without rebuilding context.
|
|
- Browser demo mode keeps mock string-save and TTL changes visible for the current session while still labeling the runtime as non-live.
|
|
- Current baseline sign-off does not require the visible `Add key` surface to pass or fail; keep any Add Key evidence separate unless PM explicitly promotes it into the active milestone.
|
|
- Delete requires a second confirmation step that includes key name and DB context.
|
|
- The command tray visibly blocks dangerous administrative commands.
|
|
- Command history marks whether each result came from the live desktop bridge or the demo shell.
|
|
|
|
## Run Notes
|
|
|
|
Use:
|
|
|
|
```bash
|
|
pnpm install
|
|
pnpm --filter @redis-gui/desktop test
|
|
pnpm run desktop:dev
|
|
```
|
|
|
|
Notes:
|
|
|
|
- `pnpm run desktop:dev` is the browser shell path. It supports layout review and session-local demo fallback only; mock save and TTL actions update visible UI state, but no Tauri or Redis mutation occurs.
|
|
- `pnpm run desktop:tauri:dev` is the desktop integration path. Use it when QA or backend needs to validate the existing command bridge against a live Redis target.
|
|
- `pnpm --filter @redis-gui/desktop test` should stay green before handing frontend foundation changes to QA or other feature teams.
|
|
- Use `pnpm run desktop:build` for a production bundle check before handing the shell to QA or integration work.
|