# FAQ

Answers to common questions about configuration, compilation, and platform support.

## Is Configuration Required?

No. Import `style` from `zyzz` to write literal CSS values without built-in design tokens.

```tsx title="Button.tsx"
import { style } from 'zyzz'

export function Button() {
  return <button {...styles.button()}>Save</button>
}

namespace styles {
  export const button = style({
    borderRadius: '6px',
    padding: '8px 16px',
  })
}
```

Use `defineConfig` when you need project-specific variables, themes, or cascade layers. The returned helpers infer those contracts. For bundled tokens, import from `zyzz/default`.

See [Getting Started](/docs/introduction/getting-started) for setup and [Themes & Tokens](https://github.com/wevm/zyzz/blob/main/docs/guides/themes.md) for custom configuration.

## Does Configuration Compile?

No. Configuration binds the authoring helpers to your variables and layers. A bundler integration, the CLI, or the compiler API transforms style definitions into executable code and emits the matching stylesheet.

Importing a config module alone does not replace that build step. Follow [Getting Started](/docs/introduction/getting-started) to connect compilation to your application.

## Are Tokens Bundled?

Core imports from `zyzz` are token-free. The optional `zyzz/default` entrypoint includes Geist colors and typography, plus spacing, radii, effects, and query scales.

```ts
import { style } from 'zyzz/default'

namespace styles {
  export const card = style({
    backgroundColor: 'background.surface',
    borderRadius: 'md',
    padding: 4,
  })
}
```

The default config provides font stacks but does not load fonts. Your application owns font loading. See [Default Theme](/docs/guides/default-theme) for the bundled values and exports.

## Why Use Callbacks?

A callback declares typed values that can change for each style application. The web compiler creates fixed CSS rules and custom-property slots. Applying the compiled style assigns values to those slots without generating CSS rules during rendering.

Callbacks require an explicit finite input type and a static object body. Arbitrary runtime calls and changing rule structure are unsupported.

See [Dynamic values](/docs/api/core/style#styles) for supported web inputs and examples. Native scalar bindings have separate [target limits](/docs/api/react-native/values).

## Can Libraries Precompile?

Yes. Publish transformed modules, declarations, and the matching CSS from the same build. Consumers load the stylesheet once and do not need to compile already-transformed library code.

Keep generated `.zyzz.json` compiler metadata beside the published entry modules when other Zyzz sources need to link their contracts. The CLI and filesystem host resolve those files without executing dependency code. Packed external asset copying remains unsupported.

See [Build & Delivery](https://github.com/wevm/zyzz/blob/main/docs/guides/compilation.md#publish-libraries) for the publishing workflow.

## Is Native Feature-Complete?

No. Shared style definitions must fit the native target's capabilities. DOM relationships, CSS cascade layers, and global styles are web semantics and are rejected by the native compiler.

Web compilation or TypeScript inference alone does not establish native rendering support. Check the target's supported behavior before sharing a definition across platforms.

> [!NOTE]
> Native static tables, variants, and dynamic scalar bindings are supported
> within their target limits. iOS and Android rendering acceptance remains
> pending.

See the [React Native API](/docs/api/react-native) and [Compatibility](https://github.com/wevm/zyzz/blob/main/docs/introduction/compatibility.md) for platform boundaries.