lxbme opened a new issue, #3453:
URL: https://github.com/apache/apisix-dashboard/issues/3453
# Tracking: dashboard ergonomics — making the common tasks less costly
## Why
The dashboard is a thin UI over the control-plane Admin API, and its value
is letting someone get productive with APISIX quickly. Most of what follows is
not a missing feature so much as a missing affordance: the data is already
there, but the UI makes you work to reach it, or leaves you without a next step.
Findings below were verified against `master` (`e76036c2`) by reading the
code and exercising a production-like build (APISIX serving `dist/` on the
admin port). Each one notes how it was checked so it can be reproduced or
refuted.
## 1. A resource that does not exist is a dead end
Open a detail URL for an id that is not there —
`/ui/routes/detail/no-such-route-xyz`, or any bookmark to something since
deleted — and the page:
- shows a loading skeleton that never resolves,
- raises a toast reading `Key not found`, which is etcd's wording surfaced
verbatim,
- still offers **Edit** and **Delete** for the resource that isn't there,
- offers no statement that the resource is missing, and no way back to the
list.
This is reachable in normal use: delete something in a second tab, or follow
a stale link. `rg -rln "notFound|NotFoundError|isNotFound" src/routes
src/components` returns nothing, so no detail page handles it.
Suggested: an explicit "this resource does not exist or was deleted" state
with a link back to the list, Edit/Delete suppressed, and the gateway's raw
error mapped to something a user can act on.
## 2. Detail pages do not say *which* resource you are looking at
Every detail page's heading is `{{name}} Detail` — literally "Route Detail".
To learn which route you opened you have to read the ID field further down the
form. With a dozen similarly-named routes this makes it easy to edit the wrong
one.
(#3441 gave each page a distinct browser-tab title, which helps when
switching tabs; the on-page heading is still generic.)
Suggested: include the resource's name or id in the heading.
## 3. Resource IDs cannot be copied
`rg -rn "CopyButton|navigator.clipboard|writeText" src/` returns nothing —
there is no copy affordance anywhere in the UI.
The id is the exact string you paste into a `curl` against the Admin API,
into a declarative config, or into another resource's `upstream_id`. Today the
only way to get it out of the dashboard is to select the text by hand. A copy
button next to the id in list and detail views is small and directly serves the
"thin wrapper you learn the API from" role.
## 4. Cross-references are opaque ids with no way to follow them
`upstream_id` and `service_id` on a route render as plain text inputs
(`FormPartRoute/index.tsx:118,164`) containing a bare id. There is no name
resolution and nothing to click; no form slice links to another resource. So
answering "which upstream is this route actually using?" means copying the id,
navigating to Upstreams, and searching.
Suggested: show the referenced resource's name alongside the id and make it
navigable. The reverse direction partly exists already (a service detail lists
its routes), so this would make the relationship legible in both directions.
## 5. Empty states exist for one resource out of twelve
`src/locales/en/common.json` has exactly one `empty` string, for services.
The other eleven list pages render a bare "No Data" table. On a fresh install —
the moment a first-time user is most likely to need a next step — almost every
page is a blank table with no indication of what to do.
Suggested: give every resource the treatment services already has, and on a
genuinely empty install point at the shortest path to a working route.
## 6. Nothing in the dashboard tells you whether a route actually works
Configuration happens on the admin port; verification happens on the data
plane port. The dashboard covers the first and says nothing about the second,
so confirming that a route you just created actually serves traffic means
leaving the UI and hand-writing a `curl`.
Proposed: a per-route "test request" drawer that prefills a runnable request
from the route's own config (method, path, `Host` when the route matches on
host), always shows the equivalent `curl` for copying, and attempts the request.
Two hard constraints shape the design, and are worth stating up front
because they rule out the obvious approach: the data plane is a **different
origin** and sends no CORS headers by default, so the browser usually cannot
read the response; and `fetch` is not permitted to set the `Host` header, so a
host-matched route cannot be reproduced from the browser even when it is
reachable. The generated command therefore has to be the dependable path, with
any in-browser send treated as best-effort and degrading to an explicit "the
browser could not read a response — run this command instead" rather than a
misleading failure.
Showing the equivalent `curl` also has value beyond testing: it makes the
Admin API legible and gives users a path from clicking to scripting.
This is implemented locally and a PR will follow.
## 7. Navigation is a flat, text-only list
Twelve sibling entries, no icons, no grouping, no breadcrumbs; deep pages (a
credential under a consumer) rely on browser Back for orientation.
Icons are the decorative half and are proposed in **#3452**, which also
labels the language control with the active language and adds a documentation
link.
Grouping and breadcrumbs are the structural half: they change how navigation
is organised rather than how it looks, so they are listed here for maintainer
input rather than proposed as settled.
## Checklist
- [ ] 1. Explicit not-found state for detail pages
- [ ] 2. Resource identity in detail page headings
- [ ] 3. Copyable resource ids
- [ ] 4. Resolved, navigable cross-references
- [ ] 5. Empty states for every resource
- [ ] 6. Per-route test request + `curl` preview — implemented, PR to follow
- [ ] 7a. Nav icons + header affordances — #3452
- [ ] 7b. Nav grouping / breadcrumbs — needs direction
Happy to take these one PR at a time, and to drop or rescope anything that
does not match where maintainers want the dashboard to go — particularly 7b.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
