# beUI Motion Components for React and Next.js

> beUI is a source-owned component library for animated React and Next.js interfaces. It fits developers who want copyable Motion components, shadcn-compatible installation, and public discovery by coding agents.

**starc007/ui-components** — Motion components for React.  Copy, paste, done.

- Repository: https://github.com/starc007/ui-components
- Website: https://beui.dev
- Stars: 1,934 · Forks: 94
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/starc007-ui-components

## beUI's Copy-Based Model for React Motion

beUI addresses a specific interface problem: React developers need animated controls and product layouts without committing an application to a large, fixed component package. Its intended users work with React, Next.js, TypeScript, Tailwind CSS, and Motion and expect to modify the implementation after installation. The README describes the approach as "Copy the source, own the code."

That model places beUI between a hosted component service and an ordinary source repository. Components are displayed through the documentation site, but installation transfers their source into the consuming application. This makes local customization direct, though it also transfers responsibility for reviewing and maintaining that code to the adopter.

The catalog covers more than animation primitives. The motion collection includes breadcrumbs, color selectors, buttons, tabs, and tooltips. Larger blocks include command palettes, file uploads, signup forms, and composed widgets. Separate collections cover AI chat layouts, prompt inputs, messages, approvals, tool results, and several kinds of charts. A developer needing one button can install one item, while a product team assembling an AI application can browse related layouts and blocks.

The README says components include keyboard behavior and reduced-motion support where applicable. That qualification matters. It does not establish that every component has identical accessibility coverage, so each selected component should be reviewed on its own. The repository maintains an accessibility-only test suite, but the documented `bun test` command does not describe broader browser interaction or visual regression testing.

## Registry Flow from Catalog Item to Application Code

beUI uses a shadcn-compatible registry rather than asking consumers to add a single beUI runtime package. The public catalog is documented at `/r/registry.json`. Each installable item can be represented by `/r/{slug}.json`, which the README says contains source and dependencies. A corresponding `/r/{slug}/raw` endpoint exposes raw source.

The repository layout follows the same separation. Motion implementations live in `components/motion/`, while agent and chart interfaces live in `components/agents/` and `components/charts/`. Public examples are kept under `components/previews/`. The file `lib/registry.ts` contains the component catalog and installation metadata, and `lib/ease.ts` holds shared animation tokens.

This architecture makes the documentation page and install command connected to actual repository files. It also means an adopter receives editable TypeScript rather than only calling functions from a package. The tradeoff appears after installation. Upstream changes do not automatically replace the copied component, and the README does not document a component upgrade or rollback procedure.

The package manifest confirms that the site itself uses React, Next.js, TypeScript, Tailwind CSS, and `motion`. It also includes dependencies for interface concerns such as positioning, virtualization, themes, icons, and animation. Consumers should therefore inspect the dependencies declared by each registry item rather than assuming that the visual effect is the only transferred package.

## Installing One beUI Component Through shadcn

The README requires an existing project configured for shadcn/ui. In that project, the named namespace installs an individual component into the application. This is the shortest documented path from the catalog to a first real component.

```bash
npx shadcn@latest add @beui/animated-toast-stack
```

This command requests `animated-toast-stack` through the `@beui` namespace. The component page contains its preview, usage example, and exact install command, so users should compare the command with the item they selected rather than treating the example as a universal setup guide.

A direct registry URL is also supported:

```bash
npx shadcn@latest add https://beui.dev/r/animated-toast-stack.json
```

The URL points to a shadcn-compatible registry item containing source and dependencies. Readers should expect the selected component to become part of the local application and then review the generated files. The README does not state the exact destination path for each item, so it should not be inferred from the command alone. If automatic installation is unsuitable, the documentation site lets developers copy the source and supporting files from the component page.

This workflow assumes an existing shadcn/ui setup. The README does not provide a complete application-creation tutorial for a blank project, nor does it list every possible dependency conflict among components.

## Running the beUI Site with Bun Checks

Contributors who need to modify component source, previews, or registry metadata can run the documentation site locally. The README says to install Bun, clone the repository, install dependencies, and start the development server.

```bash
git clone https://github.com/starc007/ui-components.git
cd ui-components
bun install
bun run dev
```

The development command invokes `next dev`. According to the README, the site should then be opened at `http://localhost:3000`. This setup is intended for work on the library and documentation site, not for installing beUI into an unrelated application.

The repository combines TypeScript checking, Biome linting, and registry validation in one command:

```bash
bun run check
```

Based on `package.json`, this runs `bun run typecheck`, `bun run lint`, and `bun run check:registry`. Those scripts invoke `tsc --noEmit`, `biome lint .`, and `bun scripts/check-registry.ts`. Accessibility tests have a separate command:

```bash
bun test
```

The test command uses Bun's test runner. The README identifies this as an accessibility-only suite and points contributors to `CONTRIBUTING.md` for the testing policy. It does not claim that this command covers all runtime behavior, screenshots, or end-to-end user flows. That limit is relevant when adding a component because passing the documented checks does not by itself establish production readiness.

## Agent Discovery Through MCP and Public Endpoints

beUI exposes several routes for coding agents. The project publishes an MCP server at `https://mcp.beui.dev/mcp`, and the README states that agents can use it to discover components and retrieve source and usage examples. No license key is required for that public server, according to the documentation.

```bash
npx skills add starc007/ui-components --skill beui
```

This command installs the `beui` skill for direct access to component discovery and composition. The README also identifies `/llms.txt` as a documentation index and `/r/registry.json` as the installable component catalog. These endpoints provide alternatives for clients that do not use MCP.

This design suits teams using agents to locate and copy existing components rather than asking an agent to generate each interface from scratch. It does introduce a source boundary for engineering review. Agent-generated commands still need to be checked against the component page and registry metadata, particularly because the installed output becomes application code.

There is also a separate beUI Pro offering. The README documents a licensed block workflow at `https://pro.beui.dev/` and a separate command for the `beui-pro` skill. The open repository and public service should not be confused with that private offering. The core repository is MIT licensed, but the README does not make the Pro catalog or templates part of the MIT repository.

## Maintenance Boundaries and Alternative Delivery Approaches

The repository is not archived, and its last push was on 2026-10-16. The listed release is `v0.2.0`, dated 2026-06-24. The package manifest marks the root package as `"private": true`, so the repository does not present itself as a normal npm-distributed UI package. Its current release line is early, with one listed version, although version numbers alone do not establish component quality.

Because installation copies source, maintenance costs fall partly on the adopter. Changes to shared tokens, dependency versions, or component conventions must be reviewed manually. The README does not document an automated update path, migration process, or rollback command. A team adopting many components also needs a policy for tracking which copies came from which beUI registry items, but the repository documentation does not specify one.

The MIT license permits use and adaptation in personal and commercial projects. That permission applies to the licensed repository code. Developers should separately inspect any component dependencies and the separate beUI Pro materials before building a licensing assessment.

A real alternative is installing components from shadcn/ui itself when its catalog already contains the required interaction. That approach follows a similar source-transfer model, but it does not provide beUI's motion, agent, or chart collections. Another approach is a conventional npm component package, which centralizes versioned distribution and imports through a package dependency. That model can simplify centralized upgrades, although it offers less direct control over component internals. beUI's distinctive choice is the curated motion catalog plus local source ownership.

## Conclusion

Developers building React or Next.js products with targeted animation should consider beUI when source ownership and selective installation outweigh maintaining copied code. Projects that require a governed package release, a documented dependency matrix, or a documented rollback process should verify those needs before adoption. The first evaluation should inspect the selected component's source, dependencies, keyboard behavior, reduced-motion handling, and registry entry.

## FAQ

### How do I install a beUI component in a React project?

In a project already configured for shadcn/ui, run the exact `npx shadcn@latest add @beui/animated-toast-stack` command shown in the README, or use the component's direct registry URL. The installed item becomes source that can be edited in the application.

### Can coding agents discover beUI components?

Yes. The README lists the public MCP server at `https://mcp.beui.dev/mcp` for discovering components and retrieving source and usage examples. It also provides `/llms.txt` and `/r/registry.json` as direct access points.

### Does beUI update copied components automatically?

The documentation does not describe automatic updates or rollback for copied component source. Users install the source into their application, so the README does not provide a documented upstream synchronization mechanism.

## Sources

- [License: MIT](https://github.com/starc007/ui-components/blob/main/LICENSE)
- [Project website](https://beui.dev)
- [README](https://github.com/starc007/ui-components/blob/main/README.md)
- [Releases](https://github.com/starc007/ui-components/releases)
- [starc007/ui-components on GitHub](https://github.com/starc007/ui-components)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/starc007-ui-components