@xaui/native 0.9.1-alpha.9 → 0.9.1-alpha.91

package/dist/system/recipe/create-recipe.d.ts

@@ -0,0 +1,31 @@
+import type { XAUITheme } from '../../theme/theme.type';
+import type { Axes, RecipeConfig, ResolvedStyles, Selection, SlotStyles, States } from './recipe.type';
+export type ResolveArgs<Variant extends string, A extends Axes<string>> = {
+    theme: XAUITheme;
+    selection?: Selection<Variant, A>;
+    states?: States;
+};
+export type TintArgs<Variant extends string, A extends Axes<string>> = ResolveArgs<Variant, A> & {
+    color: string;
+};
+export type Recipe<Slot extends string, Variant extends string, A extends Axes<Slot>> = {
+    readonly slots: readonly Slot[];
+    /** The cached pass: stable `StyleSheet` references, keyed by tokens alone. */
+    resolve(args: ResolveArgs<Variant, A>): ResolvedStyles<Slot>;
+    /**
+     * The tint pass: the same functions run again with `color`'s slices in place of the
+     * theme's tokens. Uncached and allocating, and only ever called when `color` is set.
+     */
+    tint(args: TintArgs<Variant, A>): SlotStyles<Slot>;
+};
+/**
+ * A component's style, declared once. Resolution splits in two because the two halves
+ * have different lifetimes: everything keyed by a finite token is cached forever, and
+ * an arbitrary `color` is recomputed per render — which is what keeps the cache bounded
+ * by the number of token combinations rather than by the palette users invent.
+ *
+ *     const styles = buttonRecipe.resolve({ theme, selection: { variant, size }, states })
+ *     const tint = color ? buttonRecipe.tint({ theme, color, selection, states }) : undefined
+ *     <View style={[styles.root, tint?.root, style]} />
+ */
+export declare function createRecipe<Slot extends string, Variant extends string, const A extends Axes<Slot>>(config: RecipeConfig<Slot, Variant, A>): Recipe<Slot, Variant, A>;

package/dist/system/recipe/index.d.cts

@@ -0,0 +1,4 @@
+export { createRecipe } from './create-recipe';
+export { RADIUS_KEYS, radiusAxis } from './radius-axis';
+export type { Recipe, ResolveArgs, TintArgs } from './create-recipe';
+export type { Axes, CompoundVariant, RecipeConfig, ResolvedSelection, ResolvedStyles, Selection, SlotStyle, SlotStyles, StateName, States, StyleFn, VariantColors, VariantRole, VariantTokens, } from './recipe.type';

package/dist/system/recipe/index.d.ts

@@ -0,0 +1,4 @@
+export { createRecipe } from './create-recipe';
+export { RADIUS_KEYS, radiusAxis } from './radius-axis';
+export type { Recipe, ResolveArgs, TintArgs } from './create-recipe';
+export type { Axes, CompoundVariant, RecipeConfig, ResolvedSelection, ResolvedStyles, Selection, SlotStyle, SlotStyles, StateName, States, StyleFn, VariantColors, VariantRole, VariantTokens, } from './recipe.type';

package/dist/system/recipe/radius-axis.d.cts

@@ -0,0 +1,43 @@
+import type { RadiusKey } from '../../theme/theme.type';
+import type { StyleFn } from './recipe.type';
+/**
+ * The `radius` axis, which is the same ten lines in every component that has one — a key
+ * of the radius scale, applied to one slot, overriding whatever `size` chose.
+ *
+ * It is written here rather than a third time in a recipe because that is the rule §2 bis
+ * states: extract at the second use, and by the end of P3 this axis exists in a dozen
+ * components. Nothing about it is component-specific except which slot carries the corner.
+ *
+ * ```ts
+ * variants: { size: { … }, radius: radiusAxis('root') }
+ * ```
+ *
+ * **More than one slot when a second node has to square off with the first.** A `Switch`
+ * whose track lost its capsule and kept a circular knob is half-rounded, so the axis moves
+ * both: `radiusAxis('track', 'thumb')`.
+ *
+ * The same named corner on each, not an inset-corrected one. Nesting rules would say the
+ * inner radius is the outer less the gap, but here that reaches zero before the outer does
+ * — at `xs` a 3pt track would hold a sharp-cornered knob — and two matched corners read
+ * better than one correct one.
+ *
+ * Variadic rather than an array because every call but that one passes a single slot, and
+ * `radiusAxis('root')` reads better than `radiusAxis(['root'])`.
+ *
+ * The return type is a full `Record<RadiusKey, …>` rather than a partial one, so
+ * `createRecipe` still infers `radius="3xl"` as the axis's value union and a typo in a
+ * caller's `radius` is a type error rather than a silently ignored key.
+ */
+export declare function radiusAxis<Slot extends string>(...slots: Slot[]): Record<RadiusKey, StyleFn<Slot>>;
+/**
+ * Listed rather than derived from a theme: the axis is built once at module load, before
+ * any theme exists, and `RadiusKey` is a type that no longer exists at runtime.
+ */
+/**
+ * Every radius the axis covers, in scale order.
+ *
+ * Exported because a recipe that *derives* a value from the corner — a nested well, an
+ * inner border — has to walk the same list the axis is built on, and a second copy of it
+ * would be a list that drifts.
+ */
+export declare const RADIUS_KEYS: readonly ["xs", "sm", "md", "lg", "xl", "2xl", "3xl", "4xl", "field", "full"];

package/dist/system/recipe/radius-axis.d.ts

@@ -0,0 +1,43 @@
+import type { RadiusKey } from '../../theme/theme.type';
+import type { StyleFn } from './recipe.type';
+/**
+ * The `radius` axis, which is the same ten lines in every component that has one — a key
+ * of the radius scale, applied to one slot, overriding whatever `size` chose.
+ *
+ * It is written here rather than a third time in a recipe because that is the rule §2 bis
+ * states: extract at the second use, and by the end of P3 this axis exists in a dozen
+ * components. Nothing about it is component-specific except which slot carries the corner.
+ *
+ * ```ts
+ * variants: { size: { … }, radius: radiusAxis('root') }
+ * ```
+ *
+ * **More than one slot when a second node has to square off with the first.** A `Switch`
+ * whose track lost its capsule and kept a circular knob is half-rounded, so the axis moves
+ * both: `radiusAxis('track', 'thumb')`.
+ *
+ * The same named corner on each, not an inset-corrected one. Nesting rules would say the
+ * inner radius is the outer less the gap, but here that reaches zero before the outer does
+ * — at `xs` a 3pt track would hold a sharp-cornered knob — and two matched corners read
+ * better than one correct one.
+ *
+ * Variadic rather than an array because every call but that one passes a single slot, and
+ * `radiusAxis('root')` reads better than `radiusAxis(['root'])`.
+ *
+ * The return type is a full `Record<RadiusKey, …>` rather than a partial one, so
+ * `createRecipe` still infers `radius="3xl"` as the axis's value union and a typo in a
+ * caller's `radius` is a type error rather than a silently ignored key.
+ */
+export declare function radiusAxis<Slot extends string>(...slots: Slot[]): Record<RadiusKey, StyleFn<Slot>>;
+/**
+ * Listed rather than derived from a theme: the axis is built once at module load, before
+ * any theme exists, and `RadiusKey` is a type that no longer exists at runtime.
+ */
+/**
+ * Every radius the axis covers, in scale order.
+ *
+ * Exported because a recipe that *derives* a value from the corner — a nested well, an
+ * inner border — has to walk the same list the axis is built on, and a second copy of it
+ * would be a list that drifts.
+ */
+export declare const RADIUS_KEYS: readonly ["xs", "sm", "md", "lg", "xl", "2xl", "3xl", "4xl", "field", "full"];

package/dist/system/recipe/recipe.type.d.cts

@@ -0,0 +1,81 @@
+import type { TextStyle, ViewStyle } from 'react-native';
+import type { XAUIColors, XAUITheme } from '../../theme/theme.type';
+/**
+ * A slot is a view or a text node, and a recipe writes one object per slot, so the two
+ * RN style shapes are merged rather than discriminated per slot.
+ */
+export type SlotStyle = ViewStyle & TextStyle;
+export type SlotStyles<Slot extends string> = Partial<Record<Slot, SlotStyle>>;
+/**
+ * The roles a variant consumes. The variant names tokens; `paint` says where they land.
+ *
+ * A role exists once a *state* needs the variant's own colour rather than a token named
+ * in the state function — `bgPressed` is what makes a pressed `Button` darken its own
+ * fill instead of taking a neutral wash, and `borderFocus` is the same thing for a field
+ * that has focus. Both also mean a raw `color` follows into that state, because
+ * `resolveTint` maps every declared role.
+ *
+ * **A state that reads a role must find it declared on every variant.** The merge is a
+ * shallow spread, so a `borderColor: colors.borderFocus` on a variant that names no
+ * `borderFocus` writes `undefined` over the colour `paint` had set.
+ *
+ * `bgSelected` and `fgSelected` are the same reasoning for a control that **toggles**:
+ * `bg` is the box at rest and `bgSelected` is the box once it is on, with `fgSelected`
+ * the mark that has to read against it. They are roles rather than tokens named in an
+ * `isSelected` axis for one reason — **the tint pass re-runs `paint` and the states, not
+ * the axes** — and that is what makes a raw `color` the colour a `Checkbox` checks in,
+ * rather than a colour that disappears the moment it is ticked.
+ */
+export type VariantRole = 'bg' | 'bgPressed' | 'bgSelected' | 'fg' | 'fgSelected' | 'border' | 'borderFocus';
+/** Token names per role — no colour value ever appears in a recipe. */
+export type VariantTokens = Partial<Record<VariantRole, keyof XAUIColors>>;
+/** The same roles resolved: theme colours, or the slices of a raw `color`. */
+export type VariantColors = Partial<Record<VariantRole, string>>;
+/**
+ * `disabled` is applied last of the three: a control that is both pressed and disabled
+ * has to read disabled.
+ */
+export type StateName = 'focused' | 'pressed' | 'disabled';
+export type States = Partial<Record<StateName, boolean>>;
+/** Reads the theme and the variant's resolved colours; returns one style per slot. */
+export type StyleFn<Slot extends string> = (theme: XAUITheme, colors: VariantColors) => SlotStyles<Slot>;
+/** Named axes of finite token values — `{ size: { sm: fn, md: fn } }`. */
+export type Axes<Slot extends string> = Record<string, Record<string, StyleFn<Slot>>>;
+/** One value per axis, plus the variant. Missing keys fall back to `defaultVariants`. */
+export type Selection<Variant extends string, A extends Axes<string>> = {
+    variant?: Variant;
+} & {
+    [Axis in keyof A]?: Extract<keyof A[Axis], string>;
+};
+export type CompoundVariant<Slot extends string, Variant extends string, A extends Axes<Slot>> = {
+    when: Selection<Variant, A>;
+    style: StyleFn<Slot>;
+};
+export type RecipeConfig<Slot extends string, Variant extends string, A extends Axes<Slot>> = {
+    /** Every slot the component publishes. Slots a recipe never styles resolve to `{}`. */
+    slots: readonly Slot[];
+    base?: StyleFn<Slot>;
+    variantTokens?: Record<Variant, VariantTokens>;
+    /** Where the variant's colours land — written once, and it holds for every variant. */
+    paint?: StyleFn<Slot>;
+    variants?: A;
+    /**
+     * `NoInfer` for the same reason `defaultVariants` needs it: a `when` clause **selects**
+     * from the variants `variantTokens` declared, it does not declare one. Without it a
+     * recipe whose only compound is `{ when: { variant: 'default' } }` narrows `Variant` to
+     * that single literal, and every other variant becomes a type error at the call site.
+     */
+    compoundVariants?: ReadonlyArray<CompoundVariant<Slot, NoInfer<Variant>, A>>;
+    states?: Partial<Record<StateName, StyleFn<Slot>>>;
+    /**
+     * `NoInfer`, because this is the one place a single variant name appears on its own:
+     * without it, inference reads `Variant` off `{ variant: 'primary' }` and narrows the
+     * whole recipe to that one value, so every other variant becomes a type error at the
+     * call site. `variantTokens` is the declaration; this only picks a default from it.
+     */
+    defaultVariants?: Selection<NoInfer<Variant>, A>;
+};
+/** Stable references: the same object for the same tokens, for the app's lifetime. */
+export type ResolvedStyles<Slot extends string> = Readonly<Record<Slot, SlotStyle>>;
+/** A selection with `defaultVariants` already folded in, keyed by axis name. */
+export type ResolvedSelection = Readonly<Record<string, string | undefined>>;

package/dist/system/recipe/recipe.type.d.ts

@@ -0,0 +1,81 @@
+import type { TextStyle, ViewStyle } from 'react-native';
+import type { XAUIColors, XAUITheme } from '../../theme/theme.type';
+/**
+ * A slot is a view or a text node, and a recipe writes one object per slot, so the two
+ * RN style shapes are merged rather than discriminated per slot.
+ */
+export type SlotStyle = ViewStyle & TextStyle;
+export type SlotStyles<Slot extends string> = Partial<Record<Slot, SlotStyle>>;
+/**
+ * The roles a variant consumes. The variant names tokens; `paint` says where they land.
+ *
+ * A role exists once a *state* needs the variant's own colour rather than a token named
+ * in the state function — `bgPressed` is what makes a pressed `Button` darken its own
+ * fill instead of taking a neutral wash, and `borderFocus` is the same thing for a field
+ * that has focus. Both also mean a raw `color` follows into that state, because
+ * `resolveTint` maps every declared role.
+ *
+ * **A state that reads a role must find it declared on every variant.** The merge is a
+ * shallow spread, so a `borderColor: colors.borderFocus` on a variant that names no
+ * `borderFocus` writes `undefined` over the colour `paint` had set.
+ *
+ * `bgSelected` and `fgSelected` are the same reasoning for a control that **toggles**:
+ * `bg` is the box at rest and `bgSelected` is the box once it is on, with `fgSelected`
+ * the mark that has to read against it. They are roles rather than tokens named in an
+ * `isSelected` axis for one reason — **the tint pass re-runs `paint` and the states, not
+ * the axes** — and that is what makes a raw `color` the colour a `Checkbox` checks in,
+ * rather than a colour that disappears the moment it is ticked.
+ */
+export type VariantRole = 'bg' | 'bgPressed' | 'bgSelected' | 'fg' | 'fgSelected' | 'border' | 'borderFocus';
+/** Token names per role — no colour value ever appears in a recipe. */
+export type VariantTokens = Partial<Record<VariantRole, keyof XAUIColors>>;
+/** The same roles resolved: theme colours, or the slices of a raw `color`. */
+export type VariantColors = Partial<Record<VariantRole, string>>;
+/**
+ * `disabled` is applied last of the three: a control that is both pressed and disabled
+ * has to read disabled.
+ */
+export type StateName = 'focused' | 'pressed' | 'disabled';
+export type States = Partial<Record<StateName, boolean>>;
+/** Reads the theme and the variant's resolved colours; returns one style per slot. */
+export type StyleFn<Slot extends string> = (theme: XAUITheme, colors: VariantColors) => SlotStyles<Slot>;
+/** Named axes of finite token values — `{ size: { sm: fn, md: fn } }`. */
+export type Axes<Slot extends string> = Record<string, Record<string, StyleFn<Slot>>>;
+/** One value per axis, plus the variant. Missing keys fall back to `defaultVariants`. */
+export type Selection<Variant extends string, A extends Axes<string>> = {
+    variant?: Variant;
+} & {
+    [Axis in keyof A]?: Extract<keyof A[Axis], string>;
+};
+export type CompoundVariant<Slot extends string, Variant extends string, A extends Axes<Slot>> = {
+    when: Selection<Variant, A>;
+    style: StyleFn<Slot>;
+};
+export type RecipeConfig<Slot extends string, Variant extends string, A extends Axes<Slot>> = {
+    /** Every slot the component publishes. Slots a recipe never styles resolve to `{}`. */
+    slots: readonly Slot[];
+    base?: StyleFn<Slot>;
+    variantTokens?: Record<Variant, VariantTokens>;
+    /** Where the variant's colours land — written once, and it holds for every variant. */
+    paint?: StyleFn<Slot>;
+    variants?: A;
+    /**
+     * `NoInfer` for the same reason `defaultVariants` needs it: a `when` clause **selects**
+     * from the variants `variantTokens` declared, it does not declare one. Without it a
+     * recipe whose only compound is `{ when: { variant: 'default' } }` narrows `Variant` to
+     * that single literal, and every other variant becomes a type error at the call site.
+     */
+    compoundVariants?: ReadonlyArray<CompoundVariant<Slot, NoInfer<Variant>, A>>;
+    states?: Partial<Record<StateName, StyleFn<Slot>>>;
+    /**
+     * `NoInfer`, because this is the one place a single variant name appears on its own:
+     * without it, inference reads `Variant` off `{ variant: 'primary' }` and narrows the
+     * whole recipe to that one value, so every other variant becomes a type error at the
+     * call site. `variantTokens` is the declaration; this only picks a default from it.
+     */
+    defaultVariants?: Selection<NoInfer<Variant>, A>;
+};
+/** Stable references: the same object for the same tokens, for the app's lifetime. */
+export type ResolvedStyles<Slot extends string> = Readonly<Record<Slot, SlotStyle>>;
+/** A selection with `defaultVariants` already folded in, keyed by axis name. */
+export type ResolvedSelection = Readonly<Record<string, string | undefined>>;

package/dist/system/recipe/resolve-tint.d.cts

@@ -0,0 +1,11 @@
+import type { XAUITint } from '../../theme/derive-tint';
+import type { XAUITheme } from '../../theme/theme.type';
+import type { VariantTokens } from './recipe.type';
+export declare function tintSliceFor(token: string): keyof XAUITint;
+/**
+ * The variant's roles, filled from the tint instead of the theme. Because it maps the
+ * roles the variant already declared, the tint lands exactly where the variant put its
+ * tokens — a background for `primary`, a label for `ghost`, a border for `tertiary` —
+ * with no per-variant instruction about what `color` means.
+ */
+export declare function resolveTint(tokens: VariantTokens | undefined, color: string, theme: XAUITheme): Record<string, string>;

package/dist/system/recipe/resolve-tint.d.ts

@@ -0,0 +1,11 @@
+import type { XAUITint } from '../../theme/derive-tint';
+import type { XAUITheme } from '../../theme/theme.type';
+import type { VariantTokens } from './recipe.type';
+export declare function tintSliceFor(token: string): keyof XAUITint;
+/**
+ * The variant's roles, filled from the tint instead of the theme. Because it maps the
+ * roles the variant already declared, the tint lands exactly where the variant put its
+ * tokens — a background for `primary`, a label for `ghost`, a border for `tertiary` —
+ * with no per-variant instruction about what `color` means.
+ */
+export declare function resolveTint(tokens: VariantTokens | undefined, color: string, theme: XAUITheme): Record<string, string>;

package/dist/system/recipe/style-cache.d.cts

@@ -0,0 +1,31 @@
+import type { XAUITheme } from '../../theme/theme.type';
+import type { ResolvedSelection, ResolvedStyles, SlotStyles, States } from './recipe.type';
+export type StyleCache<Slot extends string> = {
+    /** Returns the cached entry, calling `build` only on a miss. */
+    read(key: string, build: () => SlotStyles<Slot>): ResolvedStyles<Slot>;
+    /** Entry count — the cache's whole promise is that this stays bounded. */
+    readonly size: number;
+    clear(): void;
+};
+/**
+ * One cache per recipe, held for the app's lifetime. `StyleSheet.create` therefore runs
+ * once per token combination ever encountered, and slots read a stable reference after
+ * that — which is what makes `React.memo` work and what keeps a press from allocating.
+ *
+ * Per recipe rather than one shared table, so two recipes cannot collide on a key that
+ * describes only the theme, the variant and the axes.
+ */
+export declare function createStyleCache<Slot extends string>(slots: readonly Slot[]): StyleCache<Slot>;
+/**
+ * `theme.mode` belongs in the key and is not a detail: `createTheme` hashes one config
+ * into one `id` and returns both modes under it, so an id-only key would serve light
+ * styles to a dark screen.
+ *
+ * `color` is deliberately absent — it takes arbitrary values (R7), and letting one into
+ * the key would make the table grow with the colours users invent instead of with the
+ * finite token combinations. It is applied in a second, uncached pass.
+ *
+ * Axis names are sorted here so the key does not depend on the order the caller happened
+ * to pass its props in.
+ */
+export declare function cacheKey(theme: XAUITheme, selection: ResolvedSelection, states: States): string;

package/dist/system/recipe/style-cache.d.ts

@@ -0,0 +1,31 @@
+import type { XAUITheme } from '../../theme/theme.type';
+import type { ResolvedSelection, ResolvedStyles, SlotStyles, States } from './recipe.type';
+export type StyleCache<Slot extends string> = {
+    /** Returns the cached entry, calling `build` only on a miss. */
+    read(key: string, build: () => SlotStyles<Slot>): ResolvedStyles<Slot>;
+    /** Entry count — the cache's whole promise is that this stays bounded. */
+    readonly size: number;
+    clear(): void;
+};
+/**
+ * One cache per recipe, held for the app's lifetime. `StyleSheet.create` therefore runs
+ * once per token combination ever encountered, and slots read a stable reference after
+ * that — which is what makes `React.memo` work and what keeps a press from allocating.
+ *
+ * Per recipe rather than one shared table, so two recipes cannot collide on a key that
+ * describes only the theme, the variant and the axes.
+ */
+export declare function createStyleCache<Slot extends string>(slots: readonly Slot[]): StyleCache<Slot>;
+/**
+ * `theme.mode` belongs in the key and is not a detail: `createTheme` hashes one config
+ * into one `id` and returns both modes under it, so an id-only key would serve light
+ * styles to a dark screen.
+ *
+ * `color` is deliberately absent — it takes arbitrary values (R7), and letting one into
+ * the key would make the table grow with the colours users invent instead of with the
+ * finite token combinations. It is applied in a second, uncached pass.
+ *
+ * Axis names are sorted here so the key does not depend on the order the caller happened
+ * to pass its props in.
+ */
+export declare function cacheKey(theme: XAUITheme, selection: ResolvedSelection, states: States): string;

package/dist/system/recipe/variant-map.d.cts

@@ -0,0 +1,31 @@
+import type { XAUITheme } from '../../theme/theme.type';
+import type { Axes, RecipeConfig, ResolvedSelection, Selection, StateName, States, StyleFn, VariantTokens } from './recipe.type';
+/**
+ * Fixed, because two states can be active at once and the later one wins: a control that
+ * is both pressed and disabled reads disabled.
+ */
+export declare const STATE_ORDER: readonly StateName[];
+/**
+ * `defaultVariants` under the caller's choices, skipping the keys the caller left
+ * `undefined` — a component that forwards an unset prop must keep its default rather
+ * than erase it.
+ */
+export declare function resolveSelection<Variant extends string, A extends Axes<string>>(defaultVariants: Selection<Variant, A> | undefined, selection: Selection<Variant, A> | undefined): ResolvedSelection;
+/** Looks each named token up in the theme. Fails loudly — a typo is not a fallback. */
+export declare function resolveVariantColors(tokens: VariantTokens | undefined, theme: XAUITheme): Record<string, string>;
+/** The state functions that apply, in `STATE_ORDER`. Shared by both resolution passes. */
+export declare function activeStateFns<Slot extends string>(states: Partial<Record<StateName, StyleFn<Slot>>> | undefined, active: States): Array<StyleFn<Slot>>;
+/**
+ * The frozen resolution order:
+ *
+ *     base → paint → variants → compoundVariants → states
+ *
+ * `paint` sits with the variant because it *is* the variant's contribution, which leaves
+ * a compound variant and a state free to override a colour it set. The slot's own props
+ * and `style` come after all of this, at the call site — they always win.
+ *
+ * Axes are applied in declaration order, not sorted: when two axes touch the same
+ * property, the author's order in `variants` is the answer. (The cache key sorts them
+ * instead — see `cacheKey`.)
+ */
+export declare function collectStyleFns<Slot extends string, Variant extends string, A extends Axes<Slot>>(config: RecipeConfig<Slot, Variant, A>, selection: ResolvedSelection, states: States): Array<StyleFn<Slot>>;

package/dist/system/recipe/variant-map.d.ts

@@ -0,0 +1,31 @@
+import type { XAUITheme } from '../../theme/theme.type';
+import type { Axes, RecipeConfig, ResolvedSelection, Selection, StateName, States, StyleFn, VariantTokens } from './recipe.type';
+/**
+ * Fixed, because two states can be active at once and the later one wins: a control that
+ * is both pressed and disabled reads disabled.
+ */
+export declare const STATE_ORDER: readonly StateName[];
+/**
+ * `defaultVariants` under the caller's choices, skipping the keys the caller left
+ * `undefined` — a component that forwards an unset prop must keep its default rather
+ * than erase it.
+ */
+export declare function resolveSelection<Variant extends string, A extends Axes<string>>(defaultVariants: Selection<Variant, A> | undefined, selection: Selection<Variant, A> | undefined): ResolvedSelection;
+/** Looks each named token up in the theme. Fails loudly — a typo is not a fallback. */
+export declare function resolveVariantColors(tokens: VariantTokens | undefined, theme: XAUITheme): Record<string, string>;
+/** The state functions that apply, in `STATE_ORDER`. Shared by both resolution passes. */
+export declare function activeStateFns<Slot extends string>(states: Partial<Record<StateName, StyleFn<Slot>>> | undefined, active: States): Array<StyleFn<Slot>>;
+/**
+ * The frozen resolution order:
+ *
+ *     base → paint → variants → compoundVariants → states
+ *
+ * `paint` sits with the variant because it *is* the variant's contribution, which leaves
+ * a compound variant and a state free to override a colour it set. The slot's own props
+ * and `style` come after all of this, at the call site — they always win.
+ *
+ * Axes are applied in declaration order, not sorted: when two axes touch the same
+ * property, the author's order in `variants` is the answer. (The cache key sorts them
+ * instead — see `cacheKey`.)
+ */
+export declare function collectStyleFns<Slot extends string, Variant extends string, A extends Axes<Slot>>(config: RecipeConfig<Slot, Variant, A>, selection: ResolvedSelection, states: States): Array<StyleFn<Slot>>;

package/dist/system/selection-fill/index.d.cts

@@ -0,0 +1,2 @@
+export { SelectionFill } from './selection-fill';
+export type { SelectionFillProps } from './selection-fill.type';

package/dist/system/selection-fill/index.d.ts

@@ -0,0 +1,2 @@
+export { SelectionFill } from './selection-fill';
+export type { SelectionFillProps } from './selection-fill.type';

package/dist/system/selection-fill/selection-fill.d.cts

@@ -0,0 +1,22 @@
+import type { SelectionFillProps } from './selection-fill.type';
+/**
+ * The colour a control takes when it is on, and the mark that arrives with it — the
+ * `Checkbox`'s check on its accent square, the `Radio`'s dot in its accent circle.
+ *
+ * It is a node of its own rather than a background on the box, because it has to fade and
+ * grow in **without taking the border with it**, and the mark has to ride along: a check
+ * arriving before its background reads as a glitch rather than as an animation.
+ *
+ * ```tsx
+ * <SelectionFill isVisible={isSelected} style={fillStyle} animation={animation}>
+ *   <Check />
+ * </SelectionFill>
+ * ```
+ *
+ * The style is the host component's own resolved `fill` slot (R5) — this owns the motion
+ * and nothing else, which is what lets two components share it without sharing a recipe.
+ */
+export declare function SelectionFill({ isVisible, style, animation, children, }: SelectionFillProps): import("react").JSX.Element | null;
+export declare namespace SelectionFill {
+    var displayName: string;
+}

package/dist/system/selection-fill/selection-fill.d.ts

@@ -0,0 +1,22 @@
+import type { SelectionFillProps } from './selection-fill.type';
+/**
+ * The colour a control takes when it is on, and the mark that arrives with it — the
+ * `Checkbox`'s check on its accent square, the `Radio`'s dot in its accent circle.
+ *
+ * It is a node of its own rather than a background on the box, because it has to fade and
+ * grow in **without taking the border with it**, and the mark has to ride along: a check
+ * arriving before its background reads as a glitch rather than as an animation.
+ *
+ * ```tsx
+ * <SelectionFill isVisible={isSelected} style={fillStyle} animation={animation}>
+ *   <Check />
+ * </SelectionFill>
+ * ```
+ *
+ * The style is the host component's own resolved `fill` slot (R5) — this owns the motion
+ * and nothing else, which is what lets two components share it without sharing a recipe.
+ */
+export declare function SelectionFill({ isVisible, style, animation, children, }: SelectionFillProps): import("react").JSX.Element | null;
+export declare namespace SelectionFill {
+    var displayName: string;
+}

package/dist/system/selection-fill/selection-fill.type.d.cts

@@ -0,0 +1,12 @@
+import type { ReactNode } from 'react';
+import type { StyleProp, ViewStyle } from 'react-native';
+export type SelectionFillProps = {
+    /** Whether the control is on. The fill is the answer, and the mark rides on it. */
+    isVisible: boolean;
+    /** The resolved style of the host component's `fill` slot (R5). */
+    style: StyleProp<ViewStyle>;
+    /** `false` shows the fill without the fade and the scale, and mounts no worklet. */
+    animation?: boolean;
+    /** The mark — a check, a dash, a dot. It appears with the fill, never before it. */
+    children?: ReactNode;
+};

package/dist/system/selection-fill/selection-fill.type.d.ts

@@ -0,0 +1,12 @@
+import type { ReactNode } from 'react';
+import type { StyleProp, ViewStyle } from 'react-native';
+export type SelectionFillProps = {
+    /** Whether the control is on. The fill is the answer, and the mark rides on it. */
+    isVisible: boolean;
+    /** The resolved style of the host component's `fill` slot (R5). */
+    style: StyleProp<ViewStyle>;
+    /** `false` shows the fill without the fade and the scale, and mounts no worklet. */
+    animation?: boolean;
+    /** The mark — a check, a dash, a dot. It appears with the fill, never before it. */
+    children?: ReactNode;
+};

package/dist/system/slot/children-to-string.d.cts

@@ -0,0 +1,16 @@
+import type { ReactNode } from 'react';
+/**
+ * R3: the string a root should wrap in its default text slot, or `null` when it should
+ * render its children as they are.
+ *
+ * The whole tree is stringified recursively rather than the first child inspected. That
+ * is what makes `<Button>{count} items</Button>` work — children there are the array
+ * `[3, ' items']`, and an `isValidElement` check on the first entry would call it an
+ * element-free tree only by accident, while a check for "is the first child a string"
+ * would miss it outright.
+ *
+ * `null` for an empty result as much as for a tree containing an element: in both cases
+ * there is nothing to wrap, and a root's fallback — render the children — is right for
+ * both. It also keeps `<Button>{false}</Button>` from mounting an empty text node.
+ */
+export declare function childrenToString(children: ReactNode): string | null;

package/dist/system/slot/children-to-string.d.ts

@@ -0,0 +1,16 @@
+import type { ReactNode } from 'react';
+/**
+ * R3: the string a root should wrap in its default text slot, or `null` when it should
+ * render its children as they are.
+ *
+ * The whole tree is stringified recursively rather than the first child inspected. That
+ * is what makes `<Button>{count} items</Button>` work — children there are the array
+ * `[3, ' items']`, and an `isValidElement` check on the first entry would call it an
+ * element-free tree only by accident, while a check for "is the first child a string"
+ * would miss it outright.
+ *
+ * `null` for an empty result as much as for a tree containing an element: in both cases
+ * there is nothing to wrap, and a root's fallback — render the children — is right for
+ * both. It also keeps `<Button>{false}</Button>` from mounting an empty text node.
+ */
+export declare function childrenToString(children: ReactNode): string | null;

package/dist/system/slot/create-slot-context.d.cts

@@ -0,0 +1,14 @@
+import type { Provider } from 'react';
+/**
+ * A context a slot cannot read by accident. Every compound gets one, and it carries
+ * **resolved** values — style references the root already computed, not tokens for the
+ * slot to resolve again (R5).
+ *
+ * ```ts
+ * const [ButtonProvider, useButton] = createSlotContext<ButtonContext>('Button')
+ * ```
+ *
+ * The tuple is what lets each compound name its own hook, which R10 requires it to
+ * export. `name` gives both halves of the error, so there is one place to spell it.
+ */
+export declare function createSlotContext<T>(name: string): readonly [Provider<T | null>, () => T];

package/dist/system/slot/create-slot-context.d.ts

@@ -0,0 +1,14 @@
+import type { Provider } from 'react';
+/**
+ * A context a slot cannot read by accident. Every compound gets one, and it carries
+ * **resolved** values — style references the root already computed, not tokens for the
+ * slot to resolve again (R5).
+ *
+ * ```ts
+ * const [ButtonProvider, useButton] = createSlotContext<ButtonContext>('Button')
+ * ```
+ *
+ * The tuple is what lets each compound name its own hook, which R10 requires it to
+ * export. `name` gives both halves of the error, so there is one place to spell it.
+ */
+export declare function createSlotContext<T>(name: string): readonly [Provider<T | null>, () => T];

package/dist/system/slot/index.d.cts

@@ -0,0 +1,7 @@
+export { childrenToString } from './children-to-string';
+export { createSlotContext } from './create-slot-context';
+export { mergeProps } from './merge-props';
+export { mergeRefs } from './merge-refs';
+export { Slot } from './slot';
+export type { SlotProps } from './slot';
+export type { AsChildProps, MergeableProps, PossibleRef } from './slot.type';

package/dist/system/slot/index.d.ts

@@ -0,0 +1,7 @@
+export { childrenToString } from './children-to-string';
+export { createSlotContext } from './create-slot-context';
+export { mergeProps } from './merge-props';
+export { mergeRefs } from './merge-refs';
+export { Slot } from './slot';
+export type { SlotProps } from './slot';
+export type { AsChildProps, MergeableProps, PossibleRef } from './slot.type';

package/dist/system/slot/merge-props.d.cts

@@ -0,0 +1,15 @@
+import type { MergeableProps } from './slot.type';
+/**
+ * Merges a root's own props into the child it renders through `asChild` (R12). Four
+ * rules, and the child wins wherever they do not apply — it is the more specific intent:
+ *
+ * - **Event handlers compose.** Both run, ours first: the component's own behaviour (the
+ *   press state that drives its styles) happens before the child's side effect (the
+ *   navigation). Replacing one with the other is the bug this exists to prevent.
+ * - **Styles stack**, ours under the child's, so the child can override.
+ * - **`ref`s merge** through `mergeRefs`. React 19 passes `ref` as an ordinary prop, so
+ *   it arrives here rather than beside the props, and dropping it would sever the root's
+ *   handle on the node.
+ * - **Everything else: the child's value wins**, and ours fills in what it left unset.
+ */
+export declare function mergeProps(ours: MergeableProps, theirs: MergeableProps): MergeableProps;