feat(selector): add dropdown-internals theme targets for Selector & MultiSelector

[freddymeta]

What

Expose stable theme targets for the searchable-dropdown internals of Selector and MultiSelector, so consumers can restyle them via defineTheme instead of fragile structural CSS.

New targets (on existing elements — purely additive themeProps, default appearance unchanged):

Selector	MultiSelector	Element
selector-dropdown	multi-selector-dropdown	dropdown popover content wrapper
selector-search	multi-selector-search	search field wrapper
selector-search-input	multi-selector-search-input	search <input>
selector-empty	multi-selector-empty	"No results found" state
selector-section-header	multi-selector-section-header	grouped-option section titles

Each target is registered in the component's .doc.mjs theming.targets and covered by tests (the themingTargets suite validates every rendered target is documented).

Why

Restyling dropdown internals previously required brittle descendant CSS that broke whenever the DOM structure shifted. These stable, named targets make dropdown theming first-class.

Notes

This PR is the theming half of a split, per review feedback that the low-risk, purely-additive theme targets should land on their own (easier to review, avoids collision with in-flight theming PRs). The search-affordances half (a built-in search magnifier + clear button in the dropdown search field) is a separate PR that composes with these targets — it adds its own *-search-icon / *-search-clear-icon targets and does not touch the targets here.

Testing

• Selector + MultiSelector suites and the themingTargets suite pass.
• typecheck, typecheck:docs, storybook typecheck, docsite generate + test, sync-exports --check, check-sync, check-changesets, generate-token-docs --check, and eslint on the changed files all pass locally.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
astryx	Ready	Preview	Aug 1, 2026 2:27pm

[github-actions]

PR Analysis Report

📚 Storybook Preview

View Storybook for this PR
GitHub Pages may take up to a minute to hydrate after deploy.

🧪 Sandbox Preview

View Sandbox for this PR
GitHub Pages may take up to a minute to hydrate after deploy.

Modified Components

MultiSelector _{(@astryxdesign/core)} · View in Storybook

Metric	Before	After	Delta
Bundle Size (ESM)	N/A	N/A	N/A
Lines of Code	N/A	1355	-
Complexity	N/A	Very High (151)	-

Selector _{(@astryxdesign/core)} · View in Storybook

Metric	Before	After	Delta
Bundle Size (ESM)	N/A	N/A	N/A
Lines of Code	N/A	1337	-
Complexity	N/A	Very High (112)	-

Bundle Size Summary

Package	Size (ESM)	Size (CJS)	Gzipped
@astryxdesign/core	N/A	4.9KB	1.3KB

Accessibility Audit

Status: No accessibility violations detected.

---

_{Generated by PR Enrichment workflow | Storybook | Sandbox | View full report}

[cixzhang]

Two asks before this lands:

1. Split out the theming. The dropdown-internals theme targets (selector-dropdown / -search / -search-input / -empty / -section-header and the multi-selector equivalents) are purely additive and low-risk — let's land those as their own PR. It's much easier to review/merge and stays out of the way of the other Selector-family theme-target PRs in flight (#4626, #4628).

2. Search icon + clear button should be built in, not opt-in props. Rather than adding hasSearchClear, let's make the dropdown search field just have the clear (×) button and a search magnifier as part of the component — a searchable dropdown wanting a clear affordance and a search glyph is the expected default, not something each consumer opts into. That keeps the API surface smaller and behavior consistent everywhere instead of gating standard search-field affordances behind a flag (same reasoning we've been applying elsewhere — prefer built-in correct behavior over an options knob).

So: theme targets → their own PR; the search-field clear button + icon → built into the component directly (no hasSearchClear prop).

[freddymeta]

Closing in favor of #4636, which reworks the dropdown search field into a TextInput. That makes the search field themeable through the standard text-input target (plus the composed Icon targets for the magnifier/clear), so the selector-search / selector-search-input targets here would attach to elements that no longer exist and would conflict with that refactor.

The non-search targets proposed here (selector-dropdown / -empty / -section-header and the multi-selector equivalents) don't conflict and are still worth having — happy to re-raise them as a focused follow-up on top of #4636.