Compose registered providers around a children node, engine-agnostically.
Providers are sorted by ascending priority (lower = outer) and nested so the lowest-priority
provider is the outermost wrapper. createElement and resolve are supplied by the concrete
engine (React/Vue), keeping this function framework-free.
The registered providers.
The app node to wrap.
The engine's element factory.
Resolves a provider descriptor to a renderable component (DI-aware).
OptionalbaseProps: Record<string, unknown>
Props merged into every provider element (e.g. a shared context).
The wrapped node.
Design-system & provider integration for React apps.
A view provider is any component that must wrap the whole application tree (SSR and CSR): a design-system theme provider (MUI, Chakra, Mantine…), an i18n provider, a store provider, etc. Tailwind / plain-CSS design systems need none of this — they are just a stylesheet import handled by the CLI's Vite pipeline.
There are two ways to register a provider; both feed the SAME blueprint key (
stone.useReact.providers), which the CLI assembles at build time andbuildAppComponentcomposes around the app root (outermost-first by ascendingpriority).1. Imperative —
defineViewProvider(best for library components & DI-aware factories)The app's blueprint is produced by the CLI, which runs every blueprint config and blueprint middleware. A
defineBlueprintConfigblock therefore runs at build time;blueprint.addappends to the providers list:For a DI-aware provider, register a factory (it receives the container at compose time):
2. Declarative —
@ViewProvider(best for app-authored provider components)Decorate a React component class; the CLI's
SetReactViewProvidersMiddlewarediscovers it among the build's modules and adds it to the same list — no blueprint code needed:Both approaches are interchangeable and can be mixed; ordering is always by
priority.