One Engine, Many Brands
Theme with design tokens
Lesson 2 of 3
What you'll learn
- Understand tokens as the seam between brand and UI
- Map components to variables, then swap variables per tenant
- Keep component APIs identical across brands
A design token is a named value — --color-primary, --font-display, --radius — that your components reference instead of hardcoding. The components point at the token; the tenant decides the token's value. That indirection is the entire white-label theming strategy.
/* Components only ever reference the token... */
@theme inline {
--color-primary: var(--brand-primary);
}
/* ...and each tenant sets the value. */
[data-brand="acme"] { --brand-primary: oklch(0.6 0.17 150); }
[data-brand="webface"] { --brand-primary: oklch(0.56 0.21 254); }
Resolve the tenant on the server, set data-brand on <html>, and inject its token values. Every button, badge, and card recolors at once — no rebuild, no per-brand component, no forked CSS. The component API (<Button variant="primary">) is identical for every client; only the resolved color differs.
Behavior stable, tokens varied
The rule for a healthy white-label system: keep component behavior and props stable, vary tokens and copy. If a tenant needs a different component API, that's a product decision — not a theme.
The challenge resolves a component's color by reading the active tenant's tokens. Run it.
The Button asks for 'primary' and gets whatever the active tenant mapped it to. Run it for two tenants.
Next: modeling progress so the dashboard is derived, not duplicated — and packaging the whole thing for clients.
Sign in to save your progress across devices.