Skip to content

docs: document uiConfig.filters catalog filter configuration - #254

Merged
gkrajniak merged 1 commit into
platform-mesh:mainfrom
gkrajniak:doc
Sep 15, 2026
Merged

gkrajniak merged 1 commit into
platform-mesh:mainfrom
gkrajniak:doc

Conversation

@gkrajniak

Copy link
Copy Markdown
Contributor

What changed

Document the marketplace UI's new uiConfig.filters Luigi context field in
reference/components/marketplace.md, alongside the existing Configuration
table.

Why

The marketplace UI now builds its provider-catalog filter row dynamically
from uiConfig.filters instead of always rendering hardcoded Category and
Provider filters. This documents the new config surface so integrators know
how to drive the catalog's filtering UI without a UI code change.

Details

  • Added a uiConfig.filters row to the context-fields table.
  • Explained the {label, providerMetadataPath} shape: one filter control per
    entry, no entries means no filter row at all.
  • Explained that providerMetadataPath is a dot-path resolved against each
    provider's ProviderMetadata, transparently walking through JSON-encoded
    sub-objects such as spec.data (e.g. spec.data.category).
  • Explained option derivation (distinct values found across the catalog) and
    filtering semantics (selection narrows results, empty selection shows all).

🤖 Generated with Claude Code

## What changed
Document the marketplace UI's new `uiConfig.filters` Luigi context field in
`reference/components/marketplace.md`, alongside the existing Configuration
table.

## Why
The marketplace UI now builds its provider-catalog filter row dynamically
from `uiConfig.filters` instead of always rendering hardcoded Category and
Provider filters. This documents the new config surface so integrators know
how to drive the catalog's filtering UI without a UI code change.

## Details
- Added a `uiConfig.filters` row to the context-fields table.
- Explained the `{label, providerMetadataPath}` shape: one filter control per
  entry, no entries means no filter row at all.
- Explained that `providerMetadataPath` is a dot-path resolved against each
  provider's `ProviderMetadata`, transparently walking through JSON-encoded
  sub-objects such as `spec.data` (e.g. `spec.data.category`).
- Explained option derivation (distinct values found across the catalog) and
  filtering semantics (selection narrows results, empty selection shows all).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: gkrajniak <gkrajniak@gmail.com>
@gkrajniak gkrajniak self-assigned this Sep 15, 2026
@gkrajniak gkrajniak added the documentation Improvements or additions to documentation label Sep 15, 2026
@gkrajniak gkrajniak moved this to In-Review in OpenMesh - Backlog Sep 15, 2026
@gkrajniak
gkrajniak requested a review from lpgarzonr September 15, 2026 11:28
@gkrajniak
gkrajniak merged commit f6c0b1c into platform-mesh:main Sep 15, 2026
5 checks passed
@github-project-automation github-project-automation Bot moved this from In-Review to Done in OpenMesh - Backlog Sep 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants