DS

Premium Docs

Design System Showroom

Published-package documentation wired to the real DS runtime so the same routes reveal how tenant and engine reshape identical component contracts.

Rottay / modern

Published package

Primary

#0A0A0A

Rottay

Radius

14px

Surface shape

DensitynormalPlatform Flagship

NavigatorLibrary map

8 sections

212 routes

Foundations first, then primitives, patterns, structures, and surfaces. Keep this rail legible enough to scan without hunting.

Foundations4 documented routes

4

97

48

21

36

3

1

2

Runtime fingerprintToken readout from the active provider chain.

Live DS

Runtime

Platform

Rottay

Rottay / ModernPlatform Flagship

Primary

#0A0A0ASecondary #6B6B6B

Radius

14pxxl 18px

Density

normalBorder-light cards

Accent

Badge

Compact runtime evidence across 3+ token signals.

Published DS package · Component Layer · Rottay / modernShared route metadata for the active runtime, kept inline so the shell reads like a thin header band.

Palette

#0A0A0ARottay

Chrome

Modernrenderer posture

Radius

14pxsurface shape

Density

normalPlatform Flagship

Primitives

Primitives

Primitives

Active profilePlatform Flagship

Runtime postureRottay / modern

Base components arranged by category and ready for production composition.

Runtime controls

TenantRottay

97 engine-switched primitivesLocal UI building blocks

Start here before packaging flow logic

Browse the building blocks before you reach for bigger abstractions.

The primitives shelf should prove the system under real product mechanics before teams reach for higher-order packaging. Browse by job, compare live output, and decide whether the work stays local or needs to move up into patterns.

This index is strongest when it behaves like a routing map: each category should answer what kind of UI problem it solves, what good looks like, and when to escalate.

Ship a fast CRUD baseline

Cards, badges, tables, and inputs cover a surprising amount of product before you need a higher-order pattern.

Stress-test interaction quality

Buttons, inputs, selects, and toggles are where engine differences show up immediately under real usage pressure.

Judge page rhythm first

Layout primitives reveal whether the system can make dense screens feel deliberate instead of improvised.

Categories

6

Six jobs that cover local rendering, input, layout, navigation, and layered UI.

Engines

3

Classic, modern, and rustic should all stay legible through the same API.

Shared API

1

One primitive contract should travel across providers without layout drift.

Primary scope

Local UI

This layer solves rendering and interaction quality before workflow orchestration.

Taxonomy fit

Primitives should answer local rendering, spacing, control, and overlay behavior before teams start composing reusable workflows.

Primitives

Local UI building blocks

Patterns

Repeatable task behavior

Structures

Page-level framing

Surfaces

Full screen contracts

Start from the local UI problem, not the abstraction tier.Compare the same primitive across engines before you approve a visual direction.Escalate only when the interaction logic repeats across screens.

Category balance

Display

Show evidence, hierarchy, and content density.

19

Inputs

Capture intent, edits, and decisions.

25

Feedback

Explain state changes and keep users oriented.

11

Layout

Control rhythm, spacing, and responsive composition.

15

Navigation

Move users through the product without losing context.

15

Overlay

Layer high-attention UI above the page.

12

Live DS runtime

This shelf renders imported DS components through the active provider, so tenant and engine switches should be visible here before you open a detail page.

Runtime proofImported components

Preparing live DS runtime

The provider-backed component shelf loads after the route shell so the page stays responsive.

Taxonomy guide

Browse by job

Each category is framed around the screen responsibility it owns so teams can move quickly from intent to the right shelf.

Browse the taxonomy, not a flat inventory

Display

Show evidence, hierarchy, and content density.

Display primitives carry the visible payload: cards, stats, tables, avatars, tags, media, and textual structure.

Use this track when the product question is how to present information clearly, not how to orchestrate a workflow.

Typical outcome

Dashboards, record summaries, media galleries, metadata blocks

First references

Inputs

Capture intent, edits, and decisions.

Inputs are the action layer of the system, from basic buttons and fields to structured selectors, uploads, and authoring controls.

Start here when you are assembling forms, CRUD screens, filters, inline editing, or approval actions.

Typical outcome

Settings forms, creation flows, search bars, action toolbars

First references

Open AutoComplete

Feedback

Explain state changes and keep users oriented.

Feedback primitives handle alerts, toasts, progress, modals, skeletons, and operation results that make systems feel trustworthy.

Reach here when the product needs to acknowledge loading, success, warnings, errors, or interruption moments.

Typical outcome

Loading states, confirmations, notices, async outcomes

First references

Layout

Control rhythm, spacing, and responsive composition.

Layout primitives replace raw HTML scaffolding with system-aware containers like Box, Flex, Grid, Stack, and Container.

Open layout when the UI is structurally right in concept but the spacing, balance, or responsiveness still feels improvised.

Typical outcome

Page scaffolds, adaptive sections, balanced spacing systems

First references

Open AspectRatio

Navigation

Move users through the product without losing context.

Navigation primitives define pathfinding, orientation, and mode switching for both wide desktop workspaces and tighter mobile flows.

Use this set for shell navigation, tabs, view switching, anchors, breadcrumbs, and movement across hierarchies.

Typical outcome

Collection tabs, section anchors, shells, mobile navigation

First references

Open ActionDock

Overlay

Layer high-attention UI above the page.

Overlay primitives handle popovers, menus, tours, sheets, and dialogs that need their own layer, focus rules, or interruption behavior.

Choose overlay when the interaction belongs above the current surface instead of inside normal page flow.

Typical outcome

Menus, confirmations, coach marks, contextual actions

First references

Open AdaptiveOverlay

AdaptiveOverlay

Starter trays

Build fast, then escalate

Use these bundles to stand up a convincing screen quickly, then decide whether the work still belongs in primitives.

CRUD starter kit

Enough to assemble a strong collection screen before you decide whether it deserves a packaged pattern.

ButtonInputTableBadgeModal

Settings and authoring

Use these when you need validation detail and local field control without inventing custom form chrome.

FormFormFieldSelectSwitchAlert

Shell and navigation

These establish page scaffolding and view switching before full structures or surfaces enter the conversation.

BoxFlexMenuTabsDrawer

Decision support

Escalation guide

The goal is to keep work in primitives while it still depends on local rendering, and to move up only when the interaction becomes a reusable task.

Stay in primitives when

The value comes from rendering, editing, spacing, local interaction quality, or engine parity.

Jump to patterns when

You need reusable task behavior like sorting, filtering, approvals, kanban rules, or guided authoring.

Hand off to structures later

Once the task is working, structures help frame headers, rails, filters, and supporting chrome around it.

PrimitivesCurrent section

Patterns48 documented routes

Structures21 documented routes

Surfaces36 documented routes

Verticals3 documented routes

Playground1 documented routes

Developers2 documented routes

roundedtop bar · solid dividers

EngineModern