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

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

@@ -0,0 +1,18 @@
+import type { ReactNode } from 'react';
+import type { MergeableProps } from './slot.type';
+export type SlotProps = MergeableProps & {
+    children?: ReactNode;
+};
+/**
+ * The render branch behind `asChild` (R12). A root picks it instead of its own element:
+ *
+ * ```tsx
+ * const Root = asChild ? Slot : Pressable
+ * return <Root ref={ref} {...rootProps}>{children}</Root>
+ * ```
+ *
+ * One line per root, which is the point — forty-seven roots each hand-rolling a
+ * `cloneElement` and a ref merge would drift, and R12 has to hold uniformly from the
+ * first component or the ref signature of the whole core changes later.
+ */
+export declare const Slot: import("react").ForwardRefExoticComponent<Omit<SlotProps, "ref"> & import("react").RefAttributes<unknown>>;

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

@@ -0,0 +1,18 @@
+import type { ReactNode } from 'react';
+import type { MergeableProps } from './slot.type';
+export type SlotProps = MergeableProps & {
+    children?: ReactNode;
+};
+/**
+ * The render branch behind `asChild` (R12). A root picks it instead of its own element:
+ *
+ * ```tsx
+ * const Root = asChild ? Slot : Pressable
+ * return <Root ref={ref} {...rootProps}>{children}</Root>
+ * ```
+ *
+ * One line per root, which is the point — forty-seven roots each hand-rolling a
+ * `cloneElement` and a ref merge would drift, and R12 has to hold uniformly from the
+ * first component or the ref signature of the whole core changes later.
+ */
+export declare const Slot: import("react").ForwardRefExoticComponent<Omit<SlotProps, "ref"> & import("react").RefAttributes<unknown>>;

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

@@ -0,0 +1,15 @@
+import type { Ref } from 'react';
+/** Anything React accepts as a ref, plus the absence of one. */
+export type PossibleRef<T> = Ref<T> | undefined;
+/**
+ * The props `mergeProps` knows how to combine. Deliberately loose: it merges whatever a
+ * root hands to whatever child it was given, and neither side is knowable from here.
+ */
+export type MergeableProps = Record<string, unknown>;
+export type AsChildProps = {
+    /**
+     * Merge this component's props into its single child instead of rendering an element
+     * of its own — a navigation `Link` as a `Button`, a bespoke trigger as a `Select`.
+     */
+    asChild?: boolean;
+};

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

@@ -0,0 +1,15 @@
+import type { Ref } from 'react';
+/** Anything React accepts as a ref, plus the absence of one. */
+export type PossibleRef<T> = Ref<T> | undefined;
+/**
+ * The props `mergeProps` knows how to combine. Deliberately loose: it merges whatever a
+ * root hands to whatever child it was given, and neither side is knowable from here.
+ */
+export type MergeableProps = Record<string, unknown>;
+export type AsChildProps = {
+    /**
+     * Merge this component's props into its single child instead of rendering an element
+     * of its own — a navigation `Link` as a `Button`, a bespoke trigger as a `Select`.
+     */
+    asChild?: boolean;
+};

package/dist/system/style-props/index.d.cts

@@ -0,0 +1,2 @@
+export { useStyleProps } from './use-style-props';
+export type { DirectionalStyleKey, ImageStyleProps, StyleProps, TextStyleProps, ViewStyleProps, } from './style-props.type';

package/dist/system/style-props/index.d.ts

@@ -0,0 +1,2 @@
+export { useStyleProps } from './use-style-props';
+export type { DirectionalStyleKey, ImageStyleProps, StyleProps, TextStyleProps, ViewStyleProps, } from './style-props.type';

package/dist/system/style-props/style-props.type.d.cts

@@ -0,0 +1,29 @@
+import type { ImageStyle, TextStyle, ViewStyle } from 'react-native';
+/**
+ * R13 — React Native mirrors a layout under RTL through the Start/End properties and only
+ * those. A props API is exactly where someone writes `paddingLeft` without thinking, so
+ * the type removes the temptation instead of leaving it to a review.
+ */
+export type DirectionalStyleKey = 'left' | 'right' | 'paddingLeft' | 'paddingRight' | 'marginLeft' | 'marginRight' | 'borderLeftWidth' | 'borderRightWidth' | 'borderLeftColor' | 'borderRightColor' | 'borderTopLeftRadius' | 'borderTopRightRadius' | 'borderBottomLeftRadius' | 'borderBottomRightRadius';
+/**
+ * `pointerEvents` is a style key *and* a `View` prop. R14 says the component's own prop
+ * wins, so it stays the prop it has always been and is not exposed twice — the one name
+ * where the two vocabularies collide.
+ */
+type ComponentOwnedStyleKey = 'pointerEvents';
+/**
+ * The style keys of a node, exposed as props (R14). Not a maintained list: it derives
+ * from the React Native type, minus what R13 forbids.
+ *
+ * ```ts
+ * type CardProps = ViewStyleProps & { variant?: CardVariant }
+ * ```
+ */
+export type StyleProps<Style> = Omit<Style, DirectionalStyleKey | ComponentOwnedStyleKey>;
+/** A root, or any slot that renders a view. */
+export type ViewStyleProps = StyleProps<ViewStyle>;
+/** A text slot — `color`, `fontSize`, `letterSpacing`… */
+export type TextStyleProps = StyleProps<TextStyle>;
+/** An image slot — `resizeMode`, `tintColor`… */
+export type ImageStyleProps = StyleProps<ImageStyle>;
+export {};

package/dist/system/style-props/style-props.type.d.ts

@@ -0,0 +1,29 @@
+import type { ImageStyle, TextStyle, ViewStyle } from 'react-native';
+/**
+ * R13 — React Native mirrors a layout under RTL through the Start/End properties and only
+ * those. A props API is exactly where someone writes `paddingLeft` without thinking, so
+ * the type removes the temptation instead of leaving it to a review.
+ */
+export type DirectionalStyleKey = 'left' | 'right' | 'paddingLeft' | 'paddingRight' | 'marginLeft' | 'marginRight' | 'borderLeftWidth' | 'borderRightWidth' | 'borderLeftColor' | 'borderRightColor' | 'borderTopLeftRadius' | 'borderTopRightRadius' | 'borderBottomLeftRadius' | 'borderBottomRightRadius';
+/**
+ * `pointerEvents` is a style key *and* a `View` prop. R14 says the component's own prop
+ * wins, so it stays the prop it has always been and is not exposed twice — the one name
+ * where the two vocabularies collide.
+ */
+type ComponentOwnedStyleKey = 'pointerEvents';
+/**
+ * The style keys of a node, exposed as props (R14). Not a maintained list: it derives
+ * from the React Native type, minus what R13 forbids.
+ *
+ * ```ts
+ * type CardProps = ViewStyleProps & { variant?: CardVariant }
+ * ```
+ */
+export type StyleProps<Style> = Omit<Style, DirectionalStyleKey | ComponentOwnedStyleKey>;
+/** A root, or any slot that renders a view. */
+export type ViewStyleProps = StyleProps<ViewStyle>;
+/** A text slot — `color`, `fontSize`, `letterSpacing`… */
+export type TextStyleProps = StyleProps<TextStyle>;
+/** An image slot — `resizeMode`, `tintColor`… */
+export type ImageStyleProps = StyleProps<ImageStyle>;
+export {};

package/dist/system/style-props/use-style-props.d.cts

@@ -0,0 +1,16 @@
+import type { RestPropsOf, StylePropsOf } from '../../utils/style-props';
+/**
+ * `splitStyleProps`, memoized on the values (R14). A component calls it on what is left
+ * after destructuring its own props, applies the style half between the tint and its
+ * `style`, and forwards the rest:
+ *
+ * ```tsx
+ * const [styleProps, rest] = useStyleProps(props)
+ * <Pressable style={[styles.root, tint, styleProps, style]} {...rest} />
+ * ```
+ *
+ * The identity is stable while the values are, which is what a memoized child or an
+ * animated style depends on. It is keyed on a hash rather than on the object, because the
+ * object is a fresh rest-spread on every render and would never hit.
+ */
+export declare function useStyleProps<P extends object>(props: P): [StylePropsOf<P>, RestPropsOf<P>];

package/dist/system/style-props/use-style-props.d.ts

@@ -0,0 +1,16 @@
+import type { RestPropsOf, StylePropsOf } from '../../utils/style-props';
+/**
+ * `splitStyleProps`, memoized on the values (R14). A component calls it on what is left
+ * after destructuring its own props, applies the style half between the tint and its
+ * `style`, and forwards the rest:
+ *
+ * ```tsx
+ * const [styleProps, rest] = useStyleProps(props)
+ * <Pressable style={[styles.root, tint, styleProps, style]} {...rest} />
+ * ```
+ *
+ * The identity is stable while the values are, which is what a memoized child or an
+ * animated style depends on. It is keyed on a hash rather than on the object, because the
+ * object is a fresh rest-spread on every render and would never hit.
+ */
+export declare function useStyleProps<P extends object>(props: P): [StylePropsOf<P>, RestPropsOf<P>];

package/dist/theme/appearance.d.cts

@@ -0,0 +1,58 @@
+import type { ColorMode, XAUITheme } from './theme.type';
+/**
+ * What an app's chrome needs from the theme — the status bar, the navigation bar, a
+ * navigation header — and nothing about who is going to render them.
+ *
+ * The library depends on React Native and nothing else, so it cannot reach for
+ * `expo-status-bar`, React Navigation's `screenOptions` or an Android nav-bar module. What
+ * it can do is answer the question all three ask, in the two spellings they ask it in, so
+ * an app wires four values instead of re-deriving them.
+ */
+export type XAUIAppearance = {
+    /** The resolved mode — never `'system'`. */
+    colorMode: ColorMode;
+    /**
+     * The ink on the system bars, which is **the opposite of the mode**: a dark app draws
+     * light text up there.
+     *
+     * That inversion is the whole reason this exists. `barContent === colorMode` is the bug
+     * everyone writes once, and it is invisible on a simulator whose bar happens to be
+     * white — it ships as a status bar nobody can read.
+     */
+    barContent: ColorMode;
+    /** `barContent` in React Native's own `StatusBar` spelling. */
+    statusBarStyle: 'light-content' | 'dark-content';
+    /** A bar or a header's ground, and the ink that reads on it. */
+    background: string;
+    foreground: string;
+    /** The hairline under a header, for a chrome that wants an edge. */
+    border: string;
+};
+/**
+ * The theme, read as app chrome.
+ *
+ * ```tsx
+ * // React Native's own status bar — no extra dependency.
+ * const { statusBarStyle, background } = useAppearance()
+ * <StatusBar barStyle={statusBarStyle} backgroundColor={background} />
+ *
+ * // expo-status-bar, which takes the one-word form.
+ * <StatusBar style={barContent} />
+ *
+ * // Expo Router or React Navigation.
+ * <Stack screenOptions={{
+ *   headerStyle: { backgroundColor: background },
+ *   headerTintColor: foreground,
+ *   contentStyle: { backgroundColor: background },
+ * }} />
+ * ```
+ *
+ * It is a plain function over a theme rather than a hook so the mapping can be tested —
+ * the inversion above is the one line worth pinning down — and so a navigator built
+ * outside the provider can be handed a theme directly. `useAppearance` is the hook over it.
+ *
+ * **`background` rather than `surface`.** A header painted in the page's own colour
+ * disappears into it, which is the arrangement almost every app now wants; a header that
+ * is a raised bar reads `surface` off the theme itself.
+ */
+export declare function appearanceFor(theme: XAUITheme): XAUIAppearance;

package/dist/theme/appearance.d.ts

@@ -0,0 +1,58 @@
+import type { ColorMode, XAUITheme } from './theme.type';
+/**
+ * What an app's chrome needs from the theme — the status bar, the navigation bar, a
+ * navigation header — and nothing about who is going to render them.
+ *
+ * The library depends on React Native and nothing else, so it cannot reach for
+ * `expo-status-bar`, React Navigation's `screenOptions` or an Android nav-bar module. What
+ * it can do is answer the question all three ask, in the two spellings they ask it in, so
+ * an app wires four values instead of re-deriving them.
+ */
+export type XAUIAppearance = {
+    /** The resolved mode — never `'system'`. */
+    colorMode: ColorMode;
+    /**
+     * The ink on the system bars, which is **the opposite of the mode**: a dark app draws
+     * light text up there.
+     *
+     * That inversion is the whole reason this exists. `barContent === colorMode` is the bug
+     * everyone writes once, and it is invisible on a simulator whose bar happens to be
+     * white — it ships as a status bar nobody can read.
+     */
+    barContent: ColorMode;
+    /** `barContent` in React Native's own `StatusBar` spelling. */
+    statusBarStyle: 'light-content' | 'dark-content';
+    /** A bar or a header's ground, and the ink that reads on it. */
+    background: string;
+    foreground: string;
+    /** The hairline under a header, for a chrome that wants an edge. */
+    border: string;
+};
+/**
+ * The theme, read as app chrome.
+ *
+ * ```tsx
+ * // React Native's own status bar — no extra dependency.
+ * const { statusBarStyle, background } = useAppearance()
+ * <StatusBar barStyle={statusBarStyle} backgroundColor={background} />
+ *
+ * // expo-status-bar, which takes the one-word form.
+ * <StatusBar style={barContent} />
+ *
+ * // Expo Router or React Navigation.
+ * <Stack screenOptions={{
+ *   headerStyle: { backgroundColor: background },
+ *   headerTintColor: foreground,
+ *   contentStyle: { backgroundColor: background },
+ * }} />
+ * ```
+ *
+ * It is a plain function over a theme rather than a hook so the mapping can be tested —
+ * the inversion above is the one line worth pinning down — and so a navigator built
+ * outside the provider can be handed a theme directly. `useAppearance` is the hook over it.
+ *
+ * **`background` rather than `surface`.** A header painted in the page's own colour
+ * disappears into it, which is the arrangement almost every app now wants; a header that
+ * is a raised bar reads `surface` off the theme itself.
+ */
+export declare function appearanceFor(theme: XAUITheme): XAUIAppearance;

package/dist/theme/create-theme.d.cts

@@ -0,0 +1,14 @@
+import type { XAUIThemeConfig, XAUIThemeSet } from './theme.type';
+/**
+ * Build a theme once, at module level:
+ *
+ * ```ts
+ * export const appTheme = createTheme({ colors: { light: { accent: '#3b82f6' } } })
+ * ```
+ *
+ * Module level is not a style preference — it is what makes the memoization bug
+ * impossible. A literal object passed to the provider changes identity on every parent
+ * render and rebuilds every style in the app.
+ */
+export declare function createTheme(config?: XAUIThemeConfig): XAUIThemeSet;
+export declare const defaultTheme: XAUIThemeSet;

package/dist/theme/create-theme.d.ts

@@ -0,0 +1,14 @@
+import type { XAUIThemeConfig, XAUIThemeSet } from './theme.type';
+/**
+ * Build a theme once, at module level:
+ *
+ * ```ts
+ * export const appTheme = createTheme({ colors: { light: { accent: '#3b82f6' } } })
+ * ```
+ *
+ * Module level is not a style preference — it is what makes the memoization bug
+ * impossible. A literal object passed to the provider changes identity on every parent
+ * render and rebuilds every style in the app.
+ */
+export declare function createTheme(config?: XAUIThemeConfig): XAUIThemeSet;
+export declare const defaultTheme: XAUIThemeSet;

package/dist/theme/derive-colors.d.cts

@@ -0,0 +1,21 @@
+import type { XAUIDerivedColors, XAUISourceColors } from './theme.type';
+/**
+ * The derived layer: ~30 tokens computed from the source layer, never written by hand.
+ * Override `accent` and `accentPressed`, `accentSoft`, `accentSoftForeground` follow.
+ *
+ * These are HeroUI's `color-mix(in oklab, …)` formulas transposed to JS, because React
+ * Native has no `color-mix()`. Their `-hover` names became `-pressed`: what they feed is
+ * the press overlay, and the web name was a leftover.
+ *
+ * **One deliberate divergence: a pressed state always moves towards the mode's ink**
+ * (P2-API-REVIEW §E). Mixing towards the variant's own foreground — which is what their
+ * formula does — makes the direction follow the fill's lightness rather than a decision:
+ * `#9333ea` has near-white text and lightened under the finger in light mode, while
+ * `#c084fc` has dark text and darkened in dark mode. Same component, opposite gesture,
+ * nobody's choice. Towards `foreground` it is one direction — darker in light, lighter in
+ * dark — and the label's contrast rises in both instead of falling in one.
+ *
+ * The neutral fills already did this: `defaultForeground` and `surfaceForeground` *are*
+ * the ink, so only the four saturated intents ever flipped.
+ */
+export declare function deriveColors(s: XAUISourceColors): XAUIDerivedColors;

package/dist/theme/derive-colors.d.ts

@@ -0,0 +1,21 @@
+import type { XAUIDerivedColors, XAUISourceColors } from './theme.type';
+/**
+ * The derived layer: ~30 tokens computed from the source layer, never written by hand.
+ * Override `accent` and `accentPressed`, `accentSoft`, `accentSoftForeground` follow.
+ *
+ * These are HeroUI's `color-mix(in oklab, …)` formulas transposed to JS, because React
+ * Native has no `color-mix()`. Their `-hover` names became `-pressed`: what they feed is
+ * the press overlay, and the web name was a leftover.
+ *
+ * **One deliberate divergence: a pressed state always moves towards the mode's ink**
+ * (P2-API-REVIEW §E). Mixing towards the variant's own foreground — which is what their
+ * formula does — makes the direction follow the fill's lightness rather than a decision:
+ * `#9333ea` has near-white text and lightened under the finger in light mode, while
+ * `#c084fc` has dark text and darkened in dark mode. Same component, opposite gesture,
+ * nobody's choice. Towards `foreground` it is one direction — darker in light, lighter in
+ * dark — and the label's contrast rises in both instead of falling in one.
+ *
+ * The neutral fills already did this: `defaultForeground` and `surfaceForeground` *are*
+ * the ink, so only the four saturated intents ever flipped.
+ */
+export declare function deriveColors(s: XAUISourceColors): XAUIDerivedColors;

package/dist/theme/derive-tint.d.cts

@@ -0,0 +1,20 @@
+import type { XAUITheme } from './theme.type';
+/**
+ * A raw tint, expanded into the slices a variant consumes. One `color` gives the base;
+ * the other five come out of the same OKLab formulas as `deriveColors`, so a free tint
+ * behaves exactly like `accent` or `danger` — same ratios, same rendering — instead of
+ * following a parallel mechanic.
+ */
+export type XAUITint = {
+    base: string;
+    foreground: string;
+    soft: string;
+    softForeground: string;
+    pressed: string;
+    softPressed: string;
+};
+/**
+ * Memoized per tint *and* theme: sRGB → OKLab → sRGB is not free per render, and
+ * `softForeground` mixes with the theme's `foreground`, which differs between modes.
+ */
+export declare function deriveTint(tint: string, theme: XAUITheme): XAUITint;

package/dist/theme/derive-tint.d.ts

@@ -0,0 +1,20 @@
+import type { XAUITheme } from './theme.type';
+/**
+ * A raw tint, expanded into the slices a variant consumes. One `color` gives the base;
+ * the other five come out of the same OKLab formulas as `deriveColors`, so a free tint
+ * behaves exactly like `accent` or `danger` — same ratios, same rendering — instead of
+ * following a parallel mechanic.
+ */
+export type XAUITint = {
+    base: string;
+    foreground: string;
+    soft: string;
+    softForeground: string;
+    pressed: string;
+    softPressed: string;
+};
+/**
+ * Memoized per tint *and* theme: sRGB → OKLab → sRGB is not free per render, and
+ * `softForeground` mixes with the theme's `foreground`, which differs between modes.
+ */
+export declare function deriveTint(tint: string, theme: XAUITheme): XAUITint;

package/dist/theme/index.cjs

@@ -9,17 +9,20 @@
 
 
 
-var _chunk2FEDC7U5cjs = require('../chunk-2FEDC7U5.cjs');
+var _chunkV4IFH65Icjs = require('../chunk-V4IFH65I.cjs');
+require('../chunk-WDDXU3OH.cjs');
 
 
+var _chunkTVJXC4HYcjs = require('../chunk-TVJXC4HY.cjs');
 
 
 
 
-var _chunk3QBT3Q65cjs = require('../chunk-3QBT3Q65.cjs');
 
 
 
+var _chunkIIAQISBGcjs = require('../chunk-IIAQISBG.cjs');
+require('../chunk-TK44VBIE.cjs');
 
 
 
@@ -33,4 +36,9 @@ var _chunk3QBT3Q65cjs = require('../chunk-3QBT3Q65.cjs');
 
 
 
-exports.ThemeContext = _chunk3QBT3Q65cjs.ThemeContext; exports.XAUIProvider = _chunk2FEDC7U5cjs.XAUIProvider; exports.buildRadius = _chunk2FEDC7U5cjs.buildRadius; exports.buildShadows = _chunk2FEDC7U5cjs.buildShadows; exports.createTheme = _chunk2FEDC7U5cjs.createTheme; exports.defaultTheme = _chunk2FEDC7U5cjs.defaultTheme; exports.deriveColors = _chunk2FEDC7U5cjs.deriveColors; exports.deriveTint = _chunk3QBT3Q65cjs.deriveTint; exports.palette = _chunk2FEDC7U5cjs.palette; exports.primitives = _chunk2FEDC7U5cjs.primitives; exports.sourceKeys = _chunk2FEDC7U5cjs.sourceKeys; exports.tokens = _chunk2FEDC7U5cjs.tokens; exports.useColorMode = _chunk3QBT3Q65cjs.useColorMode; exports.useThemeColor = _chunk3QBT3Q65cjs.useThemeColor; exports.useXAUITheme = _chunk3QBT3Q65cjs.useXAUITheme;
+
+
+
+
+
+exports.ThemeContext = _chunkIIAQISBGcjs.ThemeContext; exports.XAUIProvider = _chunkV4IFH65Icjs.XAUIProvider; exports.appearanceFor = _chunkIIAQISBGcjs.appearanceFor; exports.buildRadius = _chunkV4IFH65Icjs.buildRadius; exports.buildShadows = _chunkV4IFH65Icjs.buildShadows; exports.createTheme = _chunkV4IFH65Icjs.createTheme; exports.defaultTheme = _chunkV4IFH65Icjs.defaultTheme; exports.deriveColors = _chunkV4IFH65Icjs.deriveColors; exports.deriveTint = _chunkTVJXC4HYcjs.deriveTint; exports.palette = _chunkV4IFH65Icjs.palette; exports.primitives = _chunkV4IFH65Icjs.primitives; exports.sourceKeys = _chunkV4IFH65Icjs.sourceKeys; exports.tokens = _chunkV4IFH65Icjs.tokens; exports.useAppearance = _chunkIIAQISBGcjs.useAppearance; exports.useColorMode = _chunkIIAQISBGcjs.useColorMode; exports.useThemeColor = _chunkIIAQISBGcjs.useThemeColor; exports.useXAUITheme = _chunkIIAQISBGcjs.useXAUITheme;