# Theming & component config
Connect every visual property to your design system.
Frontfriend separates visual decisions from component mechanics. A component reads configuration through `ffdc(config)`, while its primitive handles interaction. Configuration can define root styles, named slots, variants, sizes, compound variants and icon choices.
## Change the system at its source
Use [Theme Studio](/docs/theme-studio/) for visual editing, or the platform’s configuration editor for supported structured changes. Review the preview before saving. The published/generated configuration is a build input, not a replacement for your editable design decisions.
The property layer makes supported visual properties addressable by humans and agents. A property can affect a component root, a slot, an interactive state or a breakpoint. The exact vocabulary is derived from the component configuration.
## Keep your page code expressive
```tsx
```
Use variants to express intent. A one-off `className` override is still code your team must own and review; repeated overrides often indicate a missing system decision.
## Foundations and components
Foundations cover color, typography, spacing, density, radius, borders, shadows, opacity, blur and motion. Component configuration applies those foundations to individual controls and their named parts.
Changing a color token is a broad design decision. Changing one component slot is a narrower decision. Check the expected scope and preview both light and dark appearances.
## Refresh and validate
```bash
npx frontfriend init --force
```
Restart or rebuild the application if its framework requires it. Validate the generated CSS and inspect a representative screen. In v4 there is no Tailwind v3 plugin to paste into `tailwind.config.js`; use the CSS-first integration.
## Current authoring limitations
Save a known-good version before applying presets or broad configuration changes. Review the diff to preserve intentional local choices.