[zhuje]

Description

Description

Adds the Card primitive (Card, CardHeader, CardContent) to the next design system in @perses-dev/components

API

• Card — variant="elevated" | "outlined" (default elevated), rendered as data-variant; as="div" | "section" | "article" (default div).
• CardHeader — endElement slot for actions (boolean/null values render no trailing slot); as="div" | "header".
• CardContent — as="div" | "figure"; supports p="0" for edge-to-edge content, which the Card clips to its radius (overflow: hidden).
• All three accept the shared spacing/sizing style props via applyStyleProps, forward ref (HTMLElement), and are registered as customization slots in PersesComponents / defaultComponents so hosts can swap them through ComponentsProvider.

Design notes

• The as prop is a closed union, not an open ElementType. This is a deliberate exception to the implementation plan's "no polymorphic props" rule: the existing MUI Panel renders Card component="section" / CardHeader component="header" / CardContent component="figure", and the only alternative (role="region"/role="figure" on divs) is a semantic regression that trips jsx-a11y/prefer-tag-over-role in every consumer. The closed list keeps types simple (refs are always HTMLElement) and prevents misuse (as="button"). Rendering uses createElement because a union JSX tag fails type-checking on the div ref type.
• Scope follows the call-site audit of Perses (Panel, PanelHeader, ExploreManager, AnnotationPreview, VariablePreview): CardActions, startElement, subheader, and CardMedia had zero usages and are intentionally omitted.

Screenshots

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.
• E2E tests are stable and unlikely to be flaky.
  See e2e docs for more details. Common issues include:
  • Is the data inconsistent? You need to mock API requests.
  • Does the time change? You need to use consistent time values or mock time utilities.
  • Does it have loading states? You need to wait for loading to complete.

[github-actions]

React Doctor found no new issues. 🎉

_{Reviewed by React Doctor for commit 5ee7d19.}