Skip to content

Make the support matrix filter filter, and search operation names - #65

Merged
Neaox merged 1 commit into
mainfrom
claude/support-matrix-filter-ux
Sep 22, 2026
Merged

Neaox merged 1 commit into
mainfrom
claude/support-matrix-filter-ux

Conversation

@Neaox

@Neaox Neaox commented Sep 22, 2026

Copy link
Copy Markdown
Contributor

The support matrix filter updated its count and left every row on screen. The script
toggled the hidden class, and each row's own flex and sm:grid won the cascade. Rows
now take the hidden attribute, which preflight backs with !important.

With the filter working, the rest of the page is built around using it:

  • Clearing it: an × in the field, Esc, a "Clear filters" link beside the count, and a
    second one in the empty state.
  • Operation names: PutBucketCors, put bucket or tag finds the services that list the
    operation, with the matching operations and their status under the row. A match has to
    start at a word in the CamelCase name, so "tag" finds TagResource and not CreateStage.
    Partial and unsupported operations sort first, ahead of "+N more", since the question is
    usually whether a call will work.
  • Looser name matching: every word has to match, against the name and a form with
    punctuation removed, so cloud logs, cloudwatch-logs and CloudWatchLogs all find
    CloudWatch Logs. The matched part of the name is highlighted.
  • All / Has gaps / Complete toggles, whose counts follow the text filter. Pressing the
    active one again returns to All.
  • The query, toggle and sort live in the URL (?q=bucket&show=gaps&sort=gaps), so a
    filtered view can be linked and survives the back button from a service page.

The operation names are ~1,500 strings most visits never use, so they are served from
/support/operations.json, built from the same support manifest as the page, and fetched
on intent: the first hover or focus on the filter, or on load when the URL carries a query.
The page is 21.4 KB gzipped (30.4 KB with the names inline) and the JSON is 8.2 KB. Service
names match immediately; while the names are in flight the count says so and the empty
state waits. A failed fetch leaves service-name matching working and is retried on the next
focus.

Checked with npm run check, npm run build and npm test, and in the browser against the
built site at desktop and phone widths: filtering, both clears, Esc, the toggles, sorting,
URL restore, no request on page load, one on focus and none on refocus. The failed-fetch
path was not exercised.

The support matrix filter updated its count and left every row on screen. The script
toggled the `hidden` class, and each row's own `flex` and `sm:grid` won the cascade. Rows
now take the `hidden` attribute, which preflight backs with `!important`.

With the filter working, the rest of the page is built around using it:

- Clearing it: an × in the field, Esc, a "Clear filters" link beside the count, and a
  second one in the empty state.
- Operation names: `PutBucketCors`, `put bucket` or `tag` finds the services that list the
  operation, with the matching operations and their status under the row. A match has to
  start at a word in the CamelCase name, so "tag" finds TagResource and not CreateStage.
  Partial and unsupported operations sort first, ahead of "+N more", since the question is
  usually whether a call will work.
- Looser name matching: every word has to match, against the name and a form with
  punctuation removed, so `cloud logs`, `cloudwatch-logs` and `CloudWatchLogs` all find
  CloudWatch Logs. The matched part of the name is highlighted.
- All / Has gaps / Complete toggles, whose counts follow the text filter. Pressing the
  active one again returns to All.
- The query, toggle and sort live in the URL (`?q=bucket&show=gaps&sort=gaps`), so a
  filtered view can be linked and survives the back button from a service page.

The operation names are ~1,500 strings most visits never use, so they are served from
`/support/operations.json`, built from the same support manifest as the page, and fetched
on intent: the first hover or focus on the filter, or on load when the URL carries a query.
The page is 21.4 KB gzipped (30.4 KB with the names inline) and the JSON is 8.2 KB. Service
names match immediately; while the names are in flight the count says so and the empty
state waits. A failed fetch leaves service-name matching working and is retried on the next
focus.

Checked with `npm run check`, `npm run build` and `npm test`, and in the browser against the
built site at desktop and phone widths: filtering, both clears, Esc, the toggles, sorting,
URL restore, no request on page load, one on focus and none on refocus. The failed-fetch
path was not exercised.
@Neaox
Neaox enabled auto-merge (squash) September 22, 2026 21:41
@Neaox
Neaox merged commit 3317b6b into main Sep 22, 2026
5 checks passed
@Neaox
Neaox deleted the claude/support-matrix-filter-ux branch September 22, 2026 21:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant