130 lines
6.0 KiB
Markdown
130 lines
6.0 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
|
|
|
|
### 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.
|
|
- 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.
|
|
- 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.
|
|
|
|
## 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 active connection and active DB stay visible without opening a modal.
|
|
- Search filters the browser list and shows a no-results state.
|
|
- When search returns zero keys, the inspector switches to an empty state instead of showing the last selected key.
|
|
- 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.
|
|
- String keys show a save affordance near the value surface.
|
|
- TTL controls stay beside the inspector metadata and expose both set and remove flows.
|
|
- 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 demo fallback only.
|
|
- `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.
|