Extension Icon

UI Component Search

Search and browse components across shadcn/ui, PrimeNG, Angular Material, spartan/ui, Taiga UI, Mantine, React Spectrum, and Chakra UI
Overview

UI Component Search

Search and browse UI components across eight libraries from a single Raycast command: shadcn/ui, PrimeNG, Angular Material, spartan/ui, Taiga UI, Mantine, React Spectrum, and Chakra UI.

Results are grouped by library and can be filtered to a single library with the dropdown. For each component you can open its documentation in the browser, copy its URL, or copy its name.

How this compares to other extensions

This extension optimizes for breadth — one place to look up components across many libraries — rather than depth in any single one. If you work primarily in one of the libraries below, a dedicated extension will usually give you a richer, deeper experience (inline docs, snippets, props, etc.), and you should reach for it:

LibraryDedicated extension
shadcn/uishadcn/ui — includes a Search Components command
Chakra UIChakra UI Documentation — includes a Search Components command
MantineMantine UI Documentation — includes a Search Documentation command

The remaining five libraries (PrimeNG, Angular Material, spartan/ui, Taiga UI, and React Spectrum) are not currently covered by dedicated extensions, so this is the fastest way to browse their components inside Raycast. Reach for this extension when you want a single cross-library search; reach for the dedicated ones when you want to live in a single library's docs.

How the component lists are sourced

For future maintainers: component lists are fetched live from each library's public documentation site at runtime, parsed, then cached locally for 24 hours (src/utils/cache.ts). Seven providers also ship a static fallback list used only when the live fetch fails (see Failure handling below); that fallback is never the primary source. Every library has its own provider under src/providers/, the shared fetch/cache/fallback flow lives in src/providers/provider-helpers.ts, and all source URLs live in src/constants.ts.

If a library stops returning results, the docs site's markup almost certainly changed. Start by opening that library's source URL below and comparing it against the parsing logic in the corresponding provider file.

LibraryProvider fileSource & parsing strategy
shadcn/uisrc/providers/shadcn-provider.tsScrapes href links off the components docs page
PrimeNGsrc/providers/primeng-provider.tsScrapes links off the PrimeNG site, with a static fallback list
Angular Materialsrc/providers/material-provider.tsScrapes the component categories page, with a static fallback list
spartan/uisrc/providers/spartan-provider.tsScrapes the components page, with a static fallback list
Taiga UIsrc/providers/taiga-provider.tsParses sitemap.xml for /components/{slug} URLs, with a static fallback list
Mantinesrc/providers/mantine-provider.tsParses sitemap.xml for /core/{slug} URLs, with a static fallback list
React Spectrumsrc/providers/react-spectrum-provider.tsScrapes a component page sidebar, with a static fallback list
Chakra UIsrc/providers/chakra-provider.tsScrapes the components overview sidebar, with a static fallback list

Failure handling

Each library is fetched independently and fails soft: a markup change or network error in one library never prevents the others from loading (fetchAllComponents() in src/hooks/use-components.ts uses Promise.allSettled). No degraded library is ever silently swallowed — there are two visible states, and both cover network errors, non-OK HTTP responses, and parse failures alike:

1. Failed — the fetch produced no usable data at all (only shadcn/ui, which has no static fallback). Surfaced by:

  • A "Failed to Load" section listing each failed library with its error message.
  • A red warning icon and a (failed) suffix on that library in the filter dropdown.
  • A toast summarizing partial failures; if every library fails, an error toast is shown.

2. Using fallback data — seven providers keep a static fallback list of known component slugs (see the table above). When their live scrape fails, they serve that list so the group stays populated, but the degraded status is returned and cached alongside the components (ProviderResult.source in src/types.ts), so a broken scraper never hides behind stale fallback data. The shared fetchWithFallback() helper applies this uniformly to every fallback provider. Surfaced by:

  • A "Using fallback data" subtitle on that library's section.
  • A small yellow warning icon on each of its component rows (hover for details).
  • A yellow warning icon and a (fallback) suffix on that library in the filter dropdown.
  • A toast summarizing which libraries are on fallback data.

Because the source status is cached, a library that only ever shows the fallback state is a signal to update that provider's scraping logic.

Development

npm install
npm run dev     # run the extension in development
npm run lint    # lint
npm run build   # production build