# 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.