1000components

1000components

React components, primitives, layouts, assets, and styles for the 1000 toolkit.

Imports

Every catalog export also has a lower-case category-prefixed leaf entry at 1000components/<category>/<ExportName> and matching styles at 1000components/styles/<ExportName>.css. Four legacy all-caps constant leaves remain available for compatibility, but they are not components and do not appear in the component catalog or lifecycle aggregates.

import Checkbox from '1000components/checkboxes/Checkbox'
import '1000components/base.css'
import '1000components/styles/Checkbox.css'

Use the aggregate 1000components import with 1000components/styles.css when bundle-level tree shaking is sufficient.

Bundle Weight

Leaf entries with per-component styles ship a small fraction of the catalog. Measured from built dist artifacts after yarn build, with yarn report:consumer-bundle as the reproduction command. CSS rows follow and deduplicate @import payloads (base once plus unique component CSS); JS rows are pre-tree-shake sums over the reachable import graph:

The selective profile is roughly two orders of magnitude smaller than the barrel profile. Runtime dependencies such as react, gsap, and lucide-react are resolved by the consumer and are not part of either row. Numbers move with the catalog; run the report again instead of reusing stale figures.

Selecting A Component

1. Start with the requested intent and facets in ../../COMPONENT_SELECTION.md.
2. Compare candidates in only the relevant family section of ../../COMPONENT_FAMILIES.md.
3. Use ../../COMPONENTS.md as the fallback for unprofiled exports or for full purpose and usage prose.
4. Verify exact props, slots, compound relationships, and behavior in source and stories before writing consumer code.

Prefer reviewed, stable standalone or assembly profiles. Do not recommend a part, hook, provider, lab export, recipe, or primitive as an independent default unless it is requested or required by the selected composition. Provisional profiles and unprofiled public exports fail source validation and indicate documentation drift. Verify source and stories, disclose the drift, and repair the profile instead of treating either state as lower-confidence coverage.

Ask exactly one decision-critical question when one missing requirement separates plausible candidates. If clear requirements have no public match, report the gap instead of forcing a near miss. Never invent exports or props.

Recommended Application Controls

Not every stable export is an application control. This verified set is where application work should start; the full catalog stays available for visual work.

All seven are reviewed, stable, and unit tested. Checkbox and BouncyNotificationProvider are additionally verified against built package output in the consumer browser fixture, together with the SelectBase and DialogBase foundations they build on.

Controls, Effects, And Demos

Distinguish the three kinds of stable exports when selecting:

• Controls implement standard application semantics: selection, entry, submission, disclosure, status, and feedback. Start with the recommended set above, then compare the relevant family in ../../COMPONENT_FAMILIES.md for alternatives and trade-offs.
• Effects are visual treatments such as backdrops, cursors, loaders, and decorations. Use them inside feature panels where the treatment stays supplemental; do not build application semantics on them.
• Demos showcase a look or technique and name the application surface in their documentation. Toasts points to BouncyNotificationProvider; DropdownMenu documents its missing change callback and points to other selectors. Follow that pointer instead of shipping the demo.

The generated catalogs label role (standalone, assembly, part, hook, provider, primitive) and lifecycle tier; neither label is an application-readiness guarantee. stable records review state, not a runtime acceptance result, so verify a control in your own integration before depending on it.

Stability And Kind

The component manifest classifies the public component-related export universe for internal documentation and validation:

• stable is the default lifecycle tier.
• lab contains exports from unsorted plus components tagged WIP in their Storybook metadata.
• recipe is an independent kind derived from Components/Recipes/* story titles, so a recipe can be either stable or lab.
• Root and category hooks and providers have explicit kind and tier entries; missing classifications fail validation.

The canonical classification is component-manifest.json. Documentation and test commands reject stale or missing entries, unknown fields, unsorted overrides, and exports from internal renderer/runtime modules. Stable and lab must exactly partition the catalog universe.

Generated Documentation

Source component Markdown contains the full prose and optional leading YAML selection frontmatter described in src/docs/README.md. Together with the typed schema source, it generates four documentation projections plus a schema:

• ../../COMPONENT_SELECTION.md - intent/facet lookup, profile matrix, and coverage.
• ../../COMPONENT_FAMILIES.md - family comparison matrices.
• ../../COMPONENTS.md - comprehensive prose and import catalog.
• component-selection-index.generated.json - machine-readable selection profiles and coverage.
• component-selection.schema.json - generated JSON Schema for selection frontmatter tooling.

Run yarn docs from the workspace root only for intentional regeneration. Run yarn docs:validate to validate source docs/frontmatter and yarn docs:check to check all five generated artifacts without writing. Never hand-edit any generated artifact.

Runtime Assets

Production defaults for component audio, images, and models are owned by the component under its local assets/ directory and emitted into dist/assets with content hashes. Genuinely cross-owner media lives under src/components/shared/assets/ with an explicit asset-policy.json entry. Components resolve those files relative to their installed JavaScript chunks; consumers do not need to copy /audio, /images, /videos, or /objects folders into an application public directory.

Root public media is Storybook-owned. Caller-provided media props remain unchanged and may point to local application assets or remote URLs.