@kbach/react-native 1.0.0-beta.1 → 1.0.0-beta.11

package/dist/chunk-YOC3SHF5.mjs

@@ -0,0 +1,40 @@
+import {
+  resolveClassName
+} from "./chunk-H5Z24XX5.mjs";
+
+// src/jsxRuntimeCoreWeb.ts
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { Fragment } from "react";
+function makeElement(isStaticChildren, type, props, key) {
+  return (isStaticChildren ? _jsxs : _jsx)(type, props, key);
+}
+function processElement(resolveClassName2, type, rawProps, key, isStaticChildren) {
+  if (type === null || typeof type === "symbol" || !rawProps) {
+    return makeElement(isStaticChildren, type, rawProps ?? {}, key);
+  }
+  const { className: classStrRaw, dataSet: userDataSet, ...rest } = rawProps;
+  if (typeof classStrRaw !== "string") {
+    return makeElement(isStaticChildren, type, rawProps, key);
+  }
+  const resolved = resolveClassName2(classStrRaw);
+  const dataSet = { ...userDataSet, kb: resolved };
+  return makeElement(isStaticChildren, type, { ...rest, dataSet }, key);
+}
+function createJsxFunctionsWeb(resolveClassName2) {
+  function jsx2(type, props, key) {
+    return processElement(resolveClassName2, type, props, key, false);
+  }
+  function jsxs2(type, props, key) {
+    return processElement(resolveClassName2, type, props, key, true);
+  }
+  return { jsx: jsx2, jsxs: jsxs2 };
+}
+
+// src/jsx-runtime.web.tsx
+var { jsx, jsxs } = createJsxFunctionsWeb(resolveClassName);
+
+export {
+  Fragment,
+  jsx,
+  jsxs
+};

package/dist/index.d.mts

@@ -1,19 +1,12 @@
-import * as react from 'react';
-import { ReactNode } from 'react';
-
-interface ThemeConfig {
-    /** Plain hex only, this pass — e.g. "blue-6" -> "#2563eb" */
-    colors: Record<string, string>;
-    spacing: Record<string, number>;
-    screens: Record<string, number>;
-    darkMode: 'attribute' | 'class' | 'media';
-}
-declare const defaultTheme: ThemeConfig;
-declare function setTheme(theme: ThemeConfig): void;
-declare function getTheme(): ThemeConfig;
+export { C as ColorEntry, a as ColorScale, b as ColorsAPI, c as ContainerConfig, K as KbachConfig, T as ThemeConfig, d as ThemeMode, e as ThemeProvider, f as ThemeProviderProps, g as ThemeState, h as applyKbachConfig, i as defaultTheme, j as getGlobalDarkMode, k as getGlobalThemeMode, l as getTheme, r as resolveKbachConfig, s as setGlobalThemeMode, m as setTheme, n as subscribeGlobalDarkMode, t as toggleGlobalDarkMode, u as useColors, o as useTheme } from './useColors-C6jyCLuG.mjs';
+import 'react';
 
+type StyleValue = string | number | {
+    width: number;
+    height: number;
+};
 interface StyleObject {
-    [key: string]: string | number;
+    [key: string]: StyleValue;
 }
 /**
  * Calls the Rust engine via the KbachModule TurboModule (see
@@ -32,10 +25,9 @@ interface StyleObject {
  * whenever the mode is `'system'` (its own default), so nothing regresses
  * for apps that never touch the override API at all. This function itself
  * has no subscription of its own, so nothing re-renders just because the
- * store's value changed — call `useGlobalDarkMode()` (or consume
- * `useTheme()`'s `isDark`) somewhere in the tree for that, NOT React
- * Native's own `useColorScheme()`, which only reflects the raw OS setting
- * and would miss an explicit override entirely.
+ * store's value changed — call `useTheme()` (its `isDark`) somewhere in
+ * the tree for that, NOT React Native's own `useColorScheme()`, which only
+ * reflects the raw OS setting and would miss an explicit override entirely.
  *
  * Phase 11 originally shipped with live in-place theme switching unverified
  * (a `uiMode` toggle triggered a re-render but `Appearance.getColorScheme()`
@@ -59,90 +51,33 @@ interface StyleObject {
  * `Pressable` ever knows this, so it's passed in directly by the caller
  * (jsx-runtime, from Pressable's own style-function callback) rather than
  * queried here. Defaults to `false` for every other element type.
- */
-declare function resolveStyle(classString: string, pressed?: boolean): StyleObject;
-
-/**
- * Native port of @kbach/react's darkModeStore.ts — same architecture (a
- * single module-level store is the real source of truth;
- * ThemeProvider/useTheme are a thin, OPTIONAL wrapper around it; every
- * function here works standalone with no provider mounted anywhere), with
- * two real platform differences from the web version:
  *
- * 1. No persistence. There's no React-Native-builtin equivalent of
- *    localStorage — adding one would mean forcing a real native dependency
- *    (e.g. @react-native-async-storage/async-storage) on every consumer,
- *    even ones that don't want it. The mode always starts at 'system' on a
- *    fresh app launch. If you want persistence, read your own storage at
- *    startup (before your first render) and call setGlobalThemeMode() with
- *    the result — same "seed once, no built-in write-back" shape as
- *    seedDefaultMode() below, just driven by your own storage instead of
- *    one this package picks for you.
- * 2. No DOM to "apply" the resolved mode to. On web, applyToDom() flips a
- *    class/attribute the generated CSS's `dark:` selectors match against.
- *    On native there's no CSS at all — nativeBridge.ts's resolveStyle()
- *    reads getGlobalDarkMode() directly on every call instead of querying
- *    Appearance.getColorScheme() itself, which is what actually makes an
- *    explicit override affect rendering (previously that function always
- *    read the raw OS setting, so it had no way to reflect a user choice —
- *    see nativeBridge.ts's own comment on this for why that's the one
- *    genuinely fixed bug this change introduces, not just a new feature).
- */
-type ThemeMode = 'light' | 'dark' | 'system';
-declare function getGlobalDarkMode(): boolean;
-declare function getGlobalThemeMode(): ThemeMode;
-/** Explicit user choice — takes priority over any later `<ThemeProvider defaultMode>` seed (see `seedDefaultMode` below). Not persisted; see this module's own doc comment. */
-declare function setGlobalThemeMode(nextMode: ThemeMode): void;
-declare function toggleGlobalDarkMode(): void;
-declare function subscribeGlobalDarkMode(listener: () => void): () => void;
-
-/**
- * Reactive read of the global dark-mode store — works with or without a
- * `<ThemeProvider>` mounted anywhere in the tree, since it subscribes to
- * `darkModeStore.ts` directly. No server-snapshot argument (unlike
- * @kbach/react's web version) — React Native has no SSR concept at all,
- * so there's no third argument for `useSyncExternalStore` to need.
- */
-declare function useGlobalDarkMode(): boolean;
-
-interface ThemeProviderProps {
-    children: ReactNode;
-    /**
-     * Applied once, on this provider's first mount, but ONLY if nothing has
-     * made an explicit mode choice yet (see
-     * `darkModeStore.ts::seedDefaultMode`) — an explicit prior choice always
-     * wins over a component's own default. Unlike @kbach/react's web
-     * version, there's no persisted value to check here — see
-     * darkModeStore.ts's own doc comment on why this package doesn't persist
-     * the mode across app launches.
-     */
-    defaultMode?: ThemeMode;
-}
-/**
- * Native port of @kbach/react's `ThemeProvider` — a thin, OPTIONAL React
- * Context wrapper around `darkModeStore.ts`'s single global store, not the
- * source of truth itself. Because the store is global, MULTIPLE mounted
- * providers share the exact same `mode`/`isDark` state rather than each
- * getting their own scoped value — mounting more than one is very likely a
- * mistake (each fighting over the same state via a different
- * `defaultMode`), so this warns once in dev, matching the web version's
- * identical guard.
- */
-declare function ThemeProvider({ children, defaultMode }: ThemeProviderProps): react.JSX.Element;
-
-interface ThemeContextValue {
-    mode: ThemeMode;
-    isDark: boolean;
-    setMode: (mode: ThemeMode) => void;
-    toggle: () => void;
-}
-/**
- * Requires a `<ThemeProvider>` ancestor — throws otherwise, since a
- * component that destructures `{ mode, setMode }` genuinely needs Context
- * (unlike a component that just wants the dark/light boolean, which should
- * reach for `useGlobalDarkMode()` instead and never needs a provider at
- * all).
+ * `width` gates `sm:`/`md:`/`lg:`/`xl:`/`2xl:` against the active theme's
+ * `screens` scale (resolve_style.rs's `native_modifier_state`) — read fresh
+ * from `Dimensions.get('window').width` on every call, the same "no
+ * caching, no store" choice `colorScheme`/`pressed` already make, and for
+ * the same reason: unlike dark mode there's no explicit-override concept to
+ * preserve here (nobody manually overrides their screen width), so a plain
+ * synchronous read is enough — no need for the subscribable store
+ * darkModeStore.ts is for. As with `colorScheme`, this function has no
+ * subscription of its own, so rotating/resizing the window doesn't
+ * re-render anything by itself — call RN's own `useWindowDimensions()`
+ * somewhere in the tree for that (same role `useColorScheme()` plays for
+ * `dark:` in apps/native-sandbox/App.tsx).
+ *
+ * Falls back to `./jsEngine` (a pure-JS, no-WASM/no-native reimplementation
+ * of this same resolution logic — see that directory's own doc comments)
+ * when `KbachModule` isn't registered at all — Expo Go, which can never
+ * load ANY custom native module (not even Expo's own Modules API), so the
+ * TurboModule this file otherwise depends on simply doesn't exist there.
+ * `TurboModuleRegistry.get` (not `.getEnforcing`, which throws) is what
+ * makes this detectable at all — `get` returns `null`/`undefined` instead.
+ * A real dev-client/CLI build always has the module registered, so this
+ * fallback only ever activates in Expo Go itself; everywhere else behaves
+ * exactly as before. The JS engine covers a strict subset of what the
+ * native/WASM engines resolve (see jsEngine/resolveUtilityNative.ts) — an
+ * intentional, documented parity gap, not a bug.
  */
-declare function useTheme(): ThemeContextValue;
+declare function resolveStyle(classString: string, pressed?: boolean): StyleObject;
 
-export { type StyleObject, type ThemeConfig, type ThemeContextValue, type ThemeMode, ThemeProvider, type ThemeProviderProps, defaultTheme, getGlobalDarkMode, getGlobalThemeMode, getTheme, resolveStyle, setGlobalThemeMode, setTheme, subscribeGlobalDarkMode, toggleGlobalDarkMode, useGlobalDarkMode, useTheme };
+export { type StyleObject, resolveStyle };

package/dist/index.d.ts

@@ -1,19 +1,12 @@
-import * as react from 'react';
-import { ReactNode } from 'react';
-
-interface ThemeConfig {
-    /** Plain hex only, this pass — e.g. "blue-6" -> "#2563eb" */
-    colors: Record<string, string>;
-    spacing: Record<string, number>;
-    screens: Record<string, number>;
-    darkMode: 'attribute' | 'class' | 'media';
-}
-declare const defaultTheme: ThemeConfig;
-declare function setTheme(theme: ThemeConfig): void;
-declare function getTheme(): ThemeConfig;
+export { C as ColorEntry, a as ColorScale, b as ColorsAPI, c as ContainerConfig, K as KbachConfig, T as ThemeConfig, d as ThemeMode, e as ThemeProvider, f as ThemeProviderProps, g as ThemeState, h as applyKbachConfig, i as defaultTheme, j as getGlobalDarkMode, k as getGlobalThemeMode, l as getTheme, r as resolveKbachConfig, s as setGlobalThemeMode, m as setTheme, n as subscribeGlobalDarkMode, t as toggleGlobalDarkMode, u as useColors, o as useTheme } from './useColors-C6jyCLuG.js';
+import 'react';
 
+type StyleValue = string | number | {
+    width: number;
+    height: number;
+};
 interface StyleObject {
-    [key: string]: string | number;
+    [key: string]: StyleValue;
 }
 /**
  * Calls the Rust engine via the KbachModule TurboModule (see
@@ -32,10 +25,9 @@ interface StyleObject {
  * whenever the mode is `'system'` (its own default), so nothing regresses
  * for apps that never touch the override API at all. This function itself
  * has no subscription of its own, so nothing re-renders just because the
- * store's value changed — call `useGlobalDarkMode()` (or consume
- * `useTheme()`'s `isDark`) somewhere in the tree for that, NOT React
- * Native's own `useColorScheme()`, which only reflects the raw OS setting
- * and would miss an explicit override entirely.
+ * store's value changed — call `useTheme()` (its `isDark`) somewhere in
+ * the tree for that, NOT React Native's own `useColorScheme()`, which only
+ * reflects the raw OS setting and would miss an explicit override entirely.
  *
  * Phase 11 originally shipped with live in-place theme switching unverified
  * (a `uiMode` toggle triggered a re-render but `Appearance.getColorScheme()`
@@ -59,90 +51,33 @@ interface StyleObject {
  * `Pressable` ever knows this, so it's passed in directly by the caller
  * (jsx-runtime, from Pressable's own style-function callback) rather than
  * queried here. Defaults to `false` for every other element type.
- */
-declare function resolveStyle(classString: string, pressed?: boolean): StyleObject;
-
-/**
- * Native port of @kbach/react's darkModeStore.ts — same architecture (a
- * single module-level store is the real source of truth;
- * ThemeProvider/useTheme are a thin, OPTIONAL wrapper around it; every
- * function here works standalone with no provider mounted anywhere), with
- * two real platform differences from the web version:
  *
- * 1. No persistence. There's no React-Native-builtin equivalent of
- *    localStorage — adding one would mean forcing a real native dependency
- *    (e.g. @react-native-async-storage/async-storage) on every consumer,
- *    even ones that don't want it. The mode always starts at 'system' on a
- *    fresh app launch. If you want persistence, read your own storage at
- *    startup (before your first render) and call setGlobalThemeMode() with
- *    the result — same "seed once, no built-in write-back" shape as
- *    seedDefaultMode() below, just driven by your own storage instead of
- *    one this package picks for you.
- * 2. No DOM to "apply" the resolved mode to. On web, applyToDom() flips a
- *    class/attribute the generated CSS's `dark:` selectors match against.
- *    On native there's no CSS at all — nativeBridge.ts's resolveStyle()
- *    reads getGlobalDarkMode() directly on every call instead of querying
- *    Appearance.getColorScheme() itself, which is what actually makes an
- *    explicit override affect rendering (previously that function always
- *    read the raw OS setting, so it had no way to reflect a user choice —
- *    see nativeBridge.ts's own comment on this for why that's the one
- *    genuinely fixed bug this change introduces, not just a new feature).
- */
-type ThemeMode = 'light' | 'dark' | 'system';
-declare function getGlobalDarkMode(): boolean;
-declare function getGlobalThemeMode(): ThemeMode;
-/** Explicit user choice — takes priority over any later `<ThemeProvider defaultMode>` seed (see `seedDefaultMode` below). Not persisted; see this module's own doc comment. */
-declare function setGlobalThemeMode(nextMode: ThemeMode): void;
-declare function toggleGlobalDarkMode(): void;
-declare function subscribeGlobalDarkMode(listener: () => void): () => void;
-
-/**
- * Reactive read of the global dark-mode store — works with or without a
- * `<ThemeProvider>` mounted anywhere in the tree, since it subscribes to
- * `darkModeStore.ts` directly. No server-snapshot argument (unlike
- * @kbach/react's web version) — React Native has no SSR concept at all,
- * so there's no third argument for `useSyncExternalStore` to need.
- */
-declare function useGlobalDarkMode(): boolean;
-
-interface ThemeProviderProps {
-    children: ReactNode;
-    /**
-     * Applied once, on this provider's first mount, but ONLY if nothing has
-     * made an explicit mode choice yet (see
-     * `darkModeStore.ts::seedDefaultMode`) — an explicit prior choice always
-     * wins over a component's own default. Unlike @kbach/react's web
-     * version, there's no persisted value to check here — see
-     * darkModeStore.ts's own doc comment on why this package doesn't persist
-     * the mode across app launches.
-     */
-    defaultMode?: ThemeMode;
-}
-/**
- * Native port of @kbach/react's `ThemeProvider` — a thin, OPTIONAL React
- * Context wrapper around `darkModeStore.ts`'s single global store, not the
- * source of truth itself. Because the store is global, MULTIPLE mounted
- * providers share the exact same `mode`/`isDark` state rather than each
- * getting their own scoped value — mounting more than one is very likely a
- * mistake (each fighting over the same state via a different
- * `defaultMode`), so this warns once in dev, matching the web version's
- * identical guard.
- */
-declare function ThemeProvider({ children, defaultMode }: ThemeProviderProps): react.JSX.Element;
-
-interface ThemeContextValue {
-    mode: ThemeMode;
-    isDark: boolean;
-    setMode: (mode: ThemeMode) => void;
-    toggle: () => void;
-}
-/**
- * Requires a `<ThemeProvider>` ancestor — throws otherwise, since a
- * component that destructures `{ mode, setMode }` genuinely needs Context
- * (unlike a component that just wants the dark/light boolean, which should
- * reach for `useGlobalDarkMode()` instead and never needs a provider at
- * all).
+ * `width` gates `sm:`/`md:`/`lg:`/`xl:`/`2xl:` against the active theme's
+ * `screens` scale (resolve_style.rs's `native_modifier_state`) — read fresh
+ * from `Dimensions.get('window').width` on every call, the same "no
+ * caching, no store" choice `colorScheme`/`pressed` already make, and for
+ * the same reason: unlike dark mode there's no explicit-override concept to
+ * preserve here (nobody manually overrides their screen width), so a plain
+ * synchronous read is enough — no need for the subscribable store
+ * darkModeStore.ts is for. As with `colorScheme`, this function has no
+ * subscription of its own, so rotating/resizing the window doesn't
+ * re-render anything by itself — call RN's own `useWindowDimensions()`
+ * somewhere in the tree for that (same role `useColorScheme()` plays for
+ * `dark:` in apps/native-sandbox/App.tsx).
+ *
+ * Falls back to `./jsEngine` (a pure-JS, no-WASM/no-native reimplementation
+ * of this same resolution logic — see that directory's own doc comments)
+ * when `KbachModule` isn't registered at all — Expo Go, which can never
+ * load ANY custom native module (not even Expo's own Modules API), so the
+ * TurboModule this file otherwise depends on simply doesn't exist there.
+ * `TurboModuleRegistry.get` (not `.getEnforcing`, which throws) is what
+ * makes this detectable at all — `get` returns `null`/`undefined` instead.
+ * A real dev-client/CLI build always has the module registered, so this
+ * fallback only ever activates in Expo Go itself; everywhere else behaves
+ * exactly as before. The JS engine covers a strict subset of what the
+ * native/WASM engines resolve (see jsEngine/resolveUtilityNative.ts) — an
+ * intentional, documented parity gap, not a bug.
  */
-declare function useTheme(): ThemeContextValue;
+declare function resolveStyle(classString: string, pressed?: boolean): StyleObject;
 
-export { type StyleObject, type ThemeConfig, type ThemeContextValue, type ThemeMode, ThemeProvider, type ThemeProviderProps, defaultTheme, getGlobalDarkMode, getGlobalThemeMode, getTheme, resolveStyle, setGlobalThemeMode, setTheme, subscribeGlobalDarkMode, toggleGlobalDarkMode, useGlobalDarkMode, useTheme };
+export { type StyleObject, resolveStyle };