Design-time discoverability for the catalog-search attribute props

[field123]

Parent

#553 — Spec: one session for Elastic Path identity

What to build

A designer choosing what a search filter filters on picks from a list drawn from the connected
store, instead of typing a raw field path they have no way to discover.

Non-blocking. This is designer usability, it predates the token architecture and survives it
unchanged, and the release must not wait for it. It has no spec story for that reason — the spec
covers the identity work, and this is sized alongside it rather than part of it.

Acceptance criteria

• A designer configuring each of the three filter components picks its attribute from a list populated from the connected store, not a free-text box with a guessed default.
• The list populates reliably — resolved synchronously from data captured during canvas render, never from an asynchronous options function, which fails silently with an empty dropdown and no error.
• No component's canvas rendering changes.
• The release is demonstrably not gated on this: it can land before or after the breaking release without affecting it.

Blocked by

None (can start immediately).

The tracker's dependency graph on this issue is authoritative; this list mirrors it.

---

Below is the original ticket, kept intact — it carries the research and decisions from #486, #495, #523 and #524.

In brief

Three search filter components ask a designer to type a raw field path — something like extensions.products(specs).product_kind. Those paths come from the customer's own store configuration, so there is no way for a designer to know what to type. Today the field is free text with a guessed default.

This issue replaces the free text with a dropdown populated from the store.

Marked non-blocking: it is a usability improvement, not part of the token architecture, and the release must not wait for it.

Part of the ADR-0003 token architecture. Carried from #518. Non-blocking — the release must not gate on it.

Why

EPRefinementList and EPHierarchicalMenu take attribute paths like extensions.products(specs).product_kind that a designer cannot discover from a fixture. Catalog search keeps its canvas mock under ADR-0003 (the canvas never mounts EPCatalogSearchProviderInner at all), so this gap predates the token architecture and survives it unchanged. It is sized here rather than closed by the design-time route.

Work

Design-time discoverability for the attribute props via setControlContextData plus synchronous options:

• EPRefinementList.attribute — free text, default "brand"
• EPHierarchicalMenu.attributes — comma-separated string
• EPRangeFilter.attribute — default "price.USD.float_price"

Touches no component's canvas render.

The approach that does not work

Async prop options are impossible. options accepts an array or a synchronous function, and Studio's call site is unawaited, uncached and error-swallowing — an async options function passes registration validation and then silently renders an empty dropdown with no error. The pattern that works is fetch-during-canvas-render → setControlContextData → synchronous options, as in the Contentful and Plasmic CMS packages.

Also rejected

Mounting the catalog-search provider live in canvas. The twelve widgets gate on inEditor, not on whether a provider supplied data, and both legal previewState values force mock in canvas — so going live yields a mix: InstantSearch mounts, the twelve keep mocking, and the three autocomplete bridge components flip to live. Redefining "withData" is the silently-broken-designer-project failure the append-only rule exists to prevent.

Blocked by: nothing.

---

ADR-0003: plasmicpkgs/commerce-providers/elastic-path/docs/adr/0003-one-session-for-elastic-path-identity.md.
ADR-0004 (why registered surfaces cannot be removed): .../0004-registered-surfaces-are-append-only.md.
Map: #486. Issue set: #496.