Styling and formatting
Let your frontend own tokens, fonts, and color mode while using board-language formatting helpers.
A
JYour frontend should own its design tokens, font loading, component styles, and light/dark-mode behavior. The SDK does not ship UI components or require Cavuno’s hosted-board theme. This is the same ownership model used by open-code systems such as shadcn: theme decisions live in the consuming application.
Use Cavuno’s formatting helpers for board-owned vocabulary, dates, locations, salaries, and custom fields.
Own the visual system in your application
Define semantic variables in your global CSS or design-system package:
Load fonts through the framework’s preferred mechanism and let the application’s theme provider own color-mode state. That keeps the custom job board consistent with the rest of your product and avoids a remote board setting unexpectedly replacing application-wide design decisions.
Format a job card in the board language
formatSalaryRange returns structure, not a finished sentence: text is the amount only, timeframe is the wire enum (per_year, never a word), and bound names open-range chrome. Map the enum through your own catalog and attach From/Up to from application copy — the SDK does not join amount↔timeframe or choose chrome words (ADR-0103).
Formatting helpers require the board language so a non-English board does not silently format board-owned data in English. Omit nullable output rather than printing placeholders such as “Invalid date”.
Render custom fields from definitions
Jobs store custom-field values by definition key. Use context.customFields.job with resolveCustomFieldDisplay(language, definitions, values) to resolve labels, option keys, and display order. Multi-select returns kind: 'multi_select' with a values: string[] of resolved labels — join with Intl.ListFormat (or render chips) in the app. Never render a stored select key as if it were the visitor-facing label.
Format distances
The API always takes and returns distances in kilometres. Visitors in the United States, United Kingdom, Liberia, and Myanmar expect miles. @cavuno/board/format has the helpers that the hosted board uses for the search distance menu and the candidate commute field:
| Helper | Returns |
|---|---|
distanceUnitForCountry(countryCode) | 'mi' for US, GB, LR, and MM (MILES_COUNTRIES); 'km' for every other country and when the country is unknown. |
searchRadiusOptions(unit) | The job search presets 5, 10, 25, 50, and 100 in unit, each as { value, unit, km }. Send km as the jobs radius. |
defaultSearchRadius(unit) | The preset a city page starts at: 25 mi or 50 km. |
defaultCommuteRadiusKm(countryCode) | The commute distance used when a candidate has not set one: 40 km (25 mi) in miles countries, 50 km elsewhere. |
COMMUTE_RADIUS_MIN_KM, COMMUTE_RADIUS_MAX_KM | The accepted commute range, 1 and 250 km. |
kmToDistanceUnit(km, unit), distanceUnitToKm(value, unit), kmToMiles, milesToKm | Unit conversions without rounding. |
formatDistance(value, unit, locale?) | A short localized label such as 25 mi or 50 km, with at most one decimal. |
Pick the unit from the place being shown (a city page) or from the candidate's home place (a profile form), not from the visitor's browser locale, so the same page always shows the same unit.
Verify styling and formatting
- Switch the application’s own light/dark setting and confirm it does not depend on a Cavuno request.
- Change the board language and verify dates, locations, salary units, and your application’s chrome copy update together.
- Render select custom fields and confirm visitors see configured labels rather than stored keys.
Next, use Localization to keep requests, canonical slugs, document language, and formatting aligned.