Exact resolver APIs, recipe helpers, and hook signatures belong to SDK package reference. This page explains the concept so component guidance and live playground links do not blur into runtime internals.

The resolver layer lets the React SDK keep component families consistent while still allowing component sets and custom overrides. It is the layer behind many low-level Base UI primitives and themeable component variants.

What the resolver is for

Use the resolver model when component choice is more than a token question.

It explains why component sets change family behavior, how low-level primitives stay theme-aware, why parent components own child-part composition, and where custom components can attach without forking whole feature families.

Public import paths

Use public SDK entry points only:

• @enadhq/enad-react-sdk/client/ui-resolver
• @enadhq/enad-react-sdk/client/theme
• @enadhq/enad-react-sdk/client/storefront

Do not copy live playground resolver runtime code into application docs or examples.

Component-set flow

EnadThemeProvider can set runtime theme state for a subtree. Resolver-backed primitives read that state to choose the right component family behavior and variant defaults.

This is why componentSet is structural. It can affect component parts, recipes, and default variants, rather than only CSS variables.

Component docs pattern

Component docs use parent-led pages. If a component exposes child parts, the parent page should explain the composition model instead of creating disconnected child-part pages.

Examples:

• Header owns Header.Bar, Header.Link, Header.Panel, and Header.Drawer guidance.
• Footer owns footer slot guidance.
• Accordion owns accordion part guidance.

Related docs

• Runtime theming
• React SDK components
• Base UI components