Webority UI
One design system, two surfaces — the same components in React and Razor.
webority-ui is the shared Webority design system: one set of design tokens and one component catalogue, published as public packages and consumed by every product — the customer portals built in React and the marketing and admin sites built in Razor Pages. A control exists once in the library; every product gets it, and every improvement to it, by version bump. Nothing is restyled or re-implemented per product.
The packages
| Package | Registry | What it is |
|---|---|---|
@webority/theme | npm | The SCSS design system — the --wui-* tokens and all component CSS. Both surfaces load this same stylesheet. |
@webority/ui-react | npm | The React components — the App* primitives (AppButton, AppSelect, …) used in every customer portal. |
@webority/ui-elements | npm | Framework-agnostic <wui-*> web components — the shared behavior engine for the hard interactive controls. Internal: you never write these directly. |
Webority.Ui.Razor | NuGet | The Razor Class Library — the <app-*> tag helpers used in marketing and admin sites, mirroring the React API. |
One component, two spellings
Same component, same name, same props — only the spelling changes with the surface. React uses PascalCase components with camelCase props; Razor uses kebab-case tag helpers with kebab-case attributes:
// React (a portal screen)
<AppButton variant="primary" leftIcon="plus">Add member</AppButton>
<!-- Razor (a .cshtml page) -->
<app-button variant="primary" left-icon="plus">Add member</app-button>Both render the same markup, styled by the same theme CSS. The hard interactive controls — select, autocomplete, multiselect, phone, date picker — share one implementation (the internal <wui-*> element underneath), so keyboard behavior, accessibility and visuals cannot drift between surfaces.
Two showcases, one catalogue
This catalogue exists once per surface, with the same sidebar, the same categories and the same page structure — a page here is a page there, just in that surface's spelling:
- ui-react.webority.dev — the components as
App*, with JSX examples. - ui-razor.webority.dev — the same components as
<app-*>, with .cshtml examples.
Building a React screen? Read the React page. Writing a .cshtml? Open the same component on the Razor showcase — for example ui-react.webority.dev/#/AppButton and ui-razor.webority.dev/Components/AppButton document the same control.
Where to start
- Start with Choosing a component — pick by the need, not the look.
- Then open the component's page: overview, live examples, when-to-use guidance, do/don't, and the full props table.
- The rules that keep every product consistent: you only ever write
App*(React) or<app-*>(Razor) — never the internal<wui-*>; never hand-roll what the catalogue already has; visuals come from the theme tokens, never per-product hex values.