Catalogue integrity
One catalogue, 57 component categories
Why Gummy UI derives its public component count, routes, source links, and registry names from a single catalogue instead of maintaining parallel claims.
By Gummy UI · Published
Counts should be computed, not remembered
The public catalogue is a TypeScript data source containing 57 unique component definitions. Each entry records a slug, display name, group, description, source path, registry name, dependencies, semantics, and keyboard contract. The exported component count is calculated from that array, so the catalogue page and API do not need a separately maintained number.
A manifest-derived count is a small architectural choice with a large editorial benefit. Marketing copy, navigation, tests, and machine-readable output can all point back to an inspectable list. When an entry changes, integrity tests catch duplicate slugs or registry names and confirm that the public source and registry item exist.
Dependency groups explain the system
The catalogue groups components by implementation relationship rather than alphabet alone. Foundations lead into forms, layout and feedback, display, disclosure, selection, overlays, navigation systems, composite inputs, and data utilities. This ordering makes shared behavior visible: a date picker depends on calendar and popover ideas, while a data table builds on table and utility behavior.
Grouping also keeps the Component Lab legible. Reviewers can compare related controls and shared states without treating every entry as an isolated demo. A new category must fit the system’s dependency story, not simply increase the headline count.
Routes are views of the same record
The searchable catalogue page reads the manifest, and each static detail route resolves its entry by slug. The catalogue API returns the same groups and components as JSON. Sitemap component URLs are generated from the same list, and llms.txt expands it into canonical links with descriptions and registry locations.
This does not eliminate every possible drift. Written prose can still overstate the status of a component, and generated registry payloads can become stale if a build step is skipped. It does give verification a precise comparison point: every public surface can be tested against the same 57 records.
Status still needs evidence
A manifest entry proves identity and intended contract, not production quality on its own. The source, meaningful states, keyboard behavior, responsive layout, theme treatment, RTL logic, reduced motion, documentation, and installation path each need evidence. Gummy UI’s launch specification separates those requirements so a catalogue count cannot substitute for verification.
The same honesty applies to Pro. All 158 private blocks and six templates now have responsive source and automated implementation evidence, and the 300-definition design-kit catalogue has a versioned local materializer. The no-network Figma Starter materialization passed, but the products remain below verified and release-ready: founder review of generated browser and design evidence, Figma export and restore, protected release archives and entitlement delivery are still open. Counts are useful only when their state is as explicit as their source.