React components for CQRS and event-sourced applications built with Cratis Arc — command dialogs, typed forms, query-backed data tables, and higher-order application surfaces.
This is the owning source repository for @cratis/components. The current
package uses Cratis-owned React markup, public TypeScript types, design tokens,
stable parts, and state attributes. React Aria is an internal implementation
dependency for selected interaction primitives.
- Browse the canonical Components documentation
- Install and mount the provider
- Choose a component area
- Inspect the package source
| Area | Current package role |
|---|---|
| Command input | Typed fields, embedded forms, dialogs, and multi-step command flows |
| Data display | Query-backed tables, local-array tables, list pages, filters, and detail surfaces |
| Application surfaces | Dialogs, notifications, dropdowns, display primitives, page chrome, and toolbars |
| Structured editors | JSON content, JSON Schema, navigation, canvas, pivot, and time-oriented views |
| Styling boundary | Cratis tokens, component styles, an optional baseline theme, and stable parts |
Components consumes generated command and query contracts and React contexts from Arc packages. Arc owns those application contracts; Components owns the React markup, public component types, styling tokens, stable parts, and component behavior in this repository.
Components carries the same design intent as the rest of Cratis: building on a CQRS or event-sourced backend should feel like ordinary React. Typed commands, queries, and read models remove friction and boilerplate from the UI layer. The ecosystem is designed for productivity, quality, reliability, and AI-assisted development, with free AI skills for building with the stack.
Applications may use Arc without Components. Components does not by itself establish design-system completeness, accessibility conformance, browser coverage, or compatibility with every Arc/React/package-version combination. Verify those properties for the exact application and component profile shipped.
Install the package:
npm install @cratis/components@^4Publication status: This example targets the owner-authorized 4.0.0 npm release. When reading it from repository source before that release, verify availability with
npm view @cratis/components@4.0.0 version; source contributors use the repository workspace.
Import the semantic tokens and component structure. The baseline theme is optional:
import '@cratis/components/tokens';
import '@cratis/components/styles';
import '@cratis/components/theme'; // optional baseline appearance
import { CratisComponentsProvider } from '@cratis/components';
export const App = () => (
<CratisComponentsProvider value={{ locale: 'en-US' }} toaster>
<YourApp />
</CratisComponentsProvider>
);The package root is setup-only: import the provider and configuration helpers there, then import every component from its explicit subpath. The built-in renderer needs no additional package or configuration.
The current package manifest defines the exact React, Arc, Fundamentals, and optional Pixi peer ranges. Verify those ranges before installing the package.
- The package manifest, exports, source, and migration guide define the current Components major-version surface.
- Generated compatibility schema v2 is checked in as
compat-manifest.json. It records the authorized seven-package scope, shared version, support windows, and renderer evidence boundaries. - Workspace manifest versions in a source checkout are development inputs. Registry versions and the GitHub release created by the label-driven release policy establish release identity.
- Package existence, examples, Storybook output, and passing checks do not establish maturity, accessibility conformance, browser coverage, support, security, or production suitability.
- Direct third-party UI dependencies retained by an application keep their own package, provider, styling, and license boundaries.
- Use the exact package archive and application profile when evaluating an upgrade.
- Canonical Components documentation
- Product-owned documentation source
- Package README
- Components 3 to 4 migration guide
This project is part of Cratis — free, MIT-licensed tools for building CQRS and event-sourced applications.
- Chronicle — event-sourcing database and runtime with an Orleans-based kernel, pluggable storage, and language-agnostic gRPC contracts. Documentation
- Chronicle clients — first-class .NET SDK, plus TypeScript, Kotlin/Java, and Elixir. AI agents connect through the Chronicle MCP server.
- Arc — CQRS framework for ASP.NET Core with commands, queries, validation, authorization, and TypeScript proxy generation. Arc does not require event sourcing. Documentation
- Components — this repository. Documentation
- CLI and Workbench — inspect and diagnose Chronicle from the terminal or browser. Documentation
- Supporting projects — Fundamentals, Specifications, Synopsis, Lens, and Narrator.
- Samples — runnable event-sourcing and CQRS examples.
Release notes and announcements are published on the Cratis blog.
@cratis/components.migrator is an optional development CLI for upgrading application source from
Components 3 to 4. It uses syntax-aware codemods internally to update root imports, Button
appearance props, and value-first callbacks; it is not a runtime dependency and is only needed while
migrating. The migration guide owns its commands and manual-review stop
cases.
@cratis/eslint-plugin-components prevents migrated source from drifting back to removed APIs.
@cratis/components.conformance is different: it is a development test harness for authors of
renderer adapters, proving slot behavior, parts, state, SSR, and accessibility. Ordinary
applications do not install Conformance unless they are implementing an adapter.
Migrator, ESLint, adapters, Conformance, and Core share the repository release version. Use the
bounded >=4 <5 tooling range instead of latest; compatibility preflight validates the installed
Components migration window. All seven packages follow the repository's label-driven
release policy.
This is a framework-library repository. Component source
keeps public types, stories, and specifications near each component; export and
package verification lives under Source/scripts/.
For root and package README changes, verify the exact files explicitly:
npx markdownlint-cli2 README.md Source/README.md
npx linkinator README.md Source/README.md --markdown --recurseRelease contributors can verify the deterministic contract and evidence generator without publishing anything:
yarn verify-compat-manifest
yarn test-release-policy
yarn test-release-evidence
yarn test-renderer-adapter-matrix
yarn generate-release-evidence --output /absolute/path/to/empty/evidence-directoryThe caller-provided evidence directory is temporary/untracked output. The hosted build retains the archives and SBOMs for 30 days; npm provenance is produced separately by the OIDC-enabled Publish workflow.
Source changes follow the repository's framework rules and the applicable build, type, specification, export, package-archive, accessibility-diagnostic, and Storybook gates. Renderer adapter contributors must also run the packed lower/current package-manager matrix.
Cratis is an open community, and we are glad to help users, teams evaluating the stack, and contributors.
| Path | Destination |
|---|---|
| Questions and discussion | Cratis Discord |
| Bugs and feature requests | GitHub Issues |
| Releases | GitHub Releases |
| Contributing | Cratis contribution guide |
| Security reports | Private security reporting |
| Source license | LICENSE |
| Package notices | Source/THIRD_PARTY_NOTICES.md |