@kbach/react-native 1.0.0-beta.5 → 1.0.0-beta.7

package/README.md

@@ -96,9 +96,12 @@ Kotlin/JNI bridge, so on web this package resolves classes through the
 same Rust engine [`@kbach/react`](https://www.npmjs.com/package/@kbach/react)
 uses — WASM instead of JNI — automatically. Metro picks the right
 implementation per platform on its own via this package's `"browser"`
-export condition; your app code and JSX never change. The WASM module
-initializes itself eagerly (synchronously, at import time — no `await`
-needed before your first render, unlike a from-scratch WASM setup).
+(client bundles) and `"node"` (Expo Router's static-rendering/SSR bundles
+— a genuinely separate resolution axis from `platform: 'web'`, see
+`nativeBridge.web.ts`'s own doc comment) export conditions; your app code
+and JSX never change. The WASM module initializes itself eagerly
+(synchronously, at import time — no `await` needed before your first
+render, unlike a from-scratch WASM setup).
 
 The only thing this doesn't cover on web is an iOS-parity feature gap —
 everything web-side resolves through the exact same
@@ -106,6 +109,49 @@ everything web-side resolves through the exact same
 logic real native uses, so see this README's "What this is" section above
 for what's covered.
 
+#### Expo Router static rendering: `dark:`/responsive on the FIRST paint
+
+If you use [static rendering](https://docs.expo.dev/router/reference/static-rendering/)
+(`web.output: "static"` — Expo Router's SSR/pre-render feature), any
+`dark:`/`sm:`/etc. class on content that's part of the **initial,
+pre-rendered HTML** resolves against whatever the **server** (Node.js, no
+real display/viewport) reports — not the visiting browser's actual OS
+preference or window size. React's hydration then adopts that
+server-rendered markup as-is rather than silently overwriting it with the
+client's own (correct) values, because a `style`-attribute-only difference
+doesn't fail hydration the way a text-content mismatch does. Concretely: a
+user with their OS in dark mode can see a `dark:` class resolve to its
+*light* value on first paint, with no error or warning anywhere.
+
+**This isn't a Kbach bug** — it's the same fundamental constraint every
+OS-preference-based styling system has under SSR (Next.js's own dark-mode
+docs describe the identical problem and fix). The standard fix applies
+here unchanged: don't resolve preference-dependent classes on
+initially-server-rendered content at all; defer them to after your app has
+mounted client-side, e.g.:
+
+```tsx
+import { useEffect, useState } from 'react';
+import { Text, View } from 'react-native';
+
+function ThemedScreen() {
+  const [mounted, setMounted] = useState(false);
+  useEffect(() => setMounted(true), []);
+
+  // Neutral on the server AND on the client's first paint (matches exactly,
+  // no hydration mismatch) — only becomes preference-aware once mounted.
+  return (
+    <View className={mounted ? 'bg-gray-1 dark:bg-gray-12' : 'bg-gray-1'}>
+      <Text>Hello</Text>
+    </View>
+  );
+}
+```
+
+Content that only ever renders client-side (not part of the statically
+pre-rendered route) is unaffected — this only matters for what's visible
+before your first `useEffect` runs.
+
 ## What this is
 
 - A JSX runtime (`@kbach/react-native/jsx-runtime`) that intercepts

package/dist/{chunk-ZUE6SCTE.mjs → chunk-5WK55Z56.mjs}

@@ -1,6 +1,6 @@
 import {
   resolveStyle
-} from "./chunk-KSDFO34H.mjs";
+} from "./chunk-T3HPTH62.mjs";
 import {
   createJsxFunctions
 } from "./chunk-DLIXI5OW.mjs";