Track client operations and show inline progress
This commit is contained in:
16
docs/product/frontend-operations.md
Normal file
16
docs/product/frontend-operations.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# Frontend operation registry
|
||||
|
||||
Harbor tracks active browser mutations by operation key instead of one global `busy` flag:
|
||||
|
||||
- `connection`: start, stop and restart;
|
||||
- `serverApply`: apply the selected server;
|
||||
- `subscriptionImport`, `subscriptionRefresh`, `subscriptionDelete`;
|
||||
- `gatewayAuto`: change the active route preference.
|
||||
|
||||
Each entry is `{ status: "running", startedAt }`. A repeated operation key receives the same in-flight Promise, so a double click sends one request. A conflicting key resolves to `false` without starting its action. The symmetric conflict matrix lives in `src/web/state/operations.js`.
|
||||
|
||||
The registry only disables controls that can mutate the same domain state. Copy actions, instruction navigation and local tabs remain available during subscription refresh. Progress is announced with `role="status"`; the structured error from TASK-004 remains `role="alert"` after failure.
|
||||
|
||||
Subscription URL validation uses a latest-request runner. Starting a new validation aborts the previous signal and ignores its result even if the underlying request resolves late.
|
||||
|
||||
The registry is local transport/UI state. It does not replace backend `snapshot.operation`, change revisions or persist data. Rollback is frontend-only. A `diagnostics` key is intentionally deferred until TASK-016 adds a diagnostics operation to run.
|
||||
Reference in New Issue
Block a user