@oxyhq/bloom 1.14.0 → 1.14.1

package/src/media-flight/MediaSurface.tsx

@@ -25,7 +25,7 @@ import {
 import { Image } from 'expo-image';
 import Animated from 'react-native-reanimated';
 
-import { SLOT_IDENTITY_CHURN_LIMIT } from './constants';
+import { SLOT_IDENTITY_CHURN_LIMIT, SLOT_IDENTITY_CHURN_WINDOW_MS } from './constants';
 import { handOffFlight } from './store';
 import type { MediaSurfaceContent, MediaVideoSlot } from './types';
 import {
@@ -149,17 +149,61 @@ export const MediaSurface = memo(function MediaSurface({
   // supports.
   const [mountedSurfaceType] = useState(surfaceType);
 
-  // A slot rebuilt on every render republishes this surface to the layer on
-  // every render, which nothing at runtime reports — the picture is correct and
-  // the app is doing work in proportion to how often its rows re-render. The
-  // counter lives in an effect rather than in render: a render-phase ref write
-  // makes the React Compiler bail on the whole component.
-  const slotChurn = useRef(0);
+  // A slot rebuilt on every render re-renders this surface — and on web
+  // republishes the shared node — every time the row it lives in renders, which
+  // nothing at runtime reports: the picture is correct and the app is just
+  // doing work in proportion to its render count.
+  //
+  // What is counted is a RUN of consecutive commits that each carried a new
+  // slot, NOT how many times the slot has ever changed. The lifetime count
+  // cannot tell the defect from a correctly memoised slot: Bloom's own
+  // documented example lists `isWatched` in its deps, so its identity changes
+  // once per activation of a long-lived surface, and any such consumer reaches
+  // any fixed lifetime total eventually. It would then be told to do the thing
+  // it is already doing, with no way to make the warning stop — which is worse
+  // than not warning, because the advice is unsatisfiable. A slot rebuilt per
+  // render is different in kind: it is new on EVERY commit, including the ones
+  // where nothing it reads changed.
+  //
+  // The run must also be FAST, and that second condition is what covers the
+  // consumer who memoised everything else too. With `content` and the rest
+  // stable, `memo` skips the renders where only the parent changed, so this
+  // component commits ONLY when the slot changes — every commit carries a new
+  // slot and the run never breaks, even though there is nothing to fix and no
+  // cost to pay. Rate is what tells them apart, and it is what the warning was
+  // ever about: a slot rebuilt per render churns as fast as its row renders,
+  // while one rebuilt when its state changes moves at the speed of a finger.
+  //
+  // All three refs are written from effects rather than in render: a
+  // render-phase ref write makes the React Compiler bail on the whole
+  // component. The first effect fires only when the identity changed, and the
+  // second — declared after it, and with no dependency array, so it runs on
+  // every commit — is what reads that mark and either extends the run or
+  // clears it.
+  const slotChangedInCommit = useRef(false);
+  const slotChurnRun = useRef(0);
+  const slotChurnRunStartedAt = useRef(0);
   useEffect(() => {
-    if (renderVideo === undefined) return;
-    slotChurn.current += 1;
-    if (slotChurn.current === SLOT_IDENTITY_CHURN_LIMIT) warnSlotNotMemoised();
+    slotChangedInCommit.current = true;
   }, [renderVideo]);
+  useEffect(() => {
+    if (renderVideo === undefined || !slotChangedInCommit.current) {
+      slotChurnRun.current = 0;
+      return;
+    }
+    slotChangedInCommit.current = false;
+    const now = Date.now();
+    if (
+      slotChurnRun.current === 0 ||
+      now - slotChurnRunStartedAt.current > SLOT_IDENTITY_CHURN_WINDOW_MS
+    ) {
+      slotChurnRun.current = 1;
+      slotChurnRunStartedAt.current = now;
+      return;
+    }
+    slotChurnRun.current += 1;
+    if (slotChurnRun.current === SLOT_IDENTITY_CHURN_LIMIT) warnSlotNotMemoised();
+  });
 
   // Both arms report the same fact — "there is a picture here now" — because the
   // destination of a flight can be either, and a caller should not have to know
@@ -252,10 +296,12 @@ function warnSlotNotMemoised(): void {
   hasWarnedAboutSlotChurn = true;
   // eslint-disable-next-line no-console
   console.warn(
-    `[Bloom] A \`renderVideo\` slot changed identity ${SLOT_IDENTITY_CHURN_LIMIT} times. ` +
-      'It is part of what a media host publishes to the flight layer and is compared by ' +
-      'identity, so a slot rebuilt on every render republishes the surface on every render. ' +
-      'Wrap it in `useCallback` with the props it actually reads.',
+    `[Bloom] A \`renderVideo\` slot was a NEW function on ${SLOT_IDENTITY_CHURN_LIMIT} ` +
+      'consecutive renders, including ones where nothing it reads changed. The slot is ' +
+      'compared by identity — on web it is part of what a media host publishes to the ' +
+      'flight layer — so one rebuilt per render re-renders the surface per render. Wrap ' +
+      'it in `useCallback` with the props it actually reads. A slot that changes when ' +
+      'those props change is fine and does not reach this.',
   );
 }
 

package/src/media-flight/constants.ts

@@ -32,16 +32,41 @@ export const SURFACE_MOUNT_TIMEOUT_MS = 250;
  */
 
 /**
- * How many times a video slot may change identity before Bloom says so.
+ * How many CONSECUTIVE renders a video slot may arrive new on before Bloom says
+ * so.
  *
- * `renderVideo` is part of what a host publishes to the layer and is compared
- * by identity, so an unmemoised slot republishes on every render of the row it
- * lives in — silently, and only under load. Five is well past any legitimate
- * cause (a mute toggle, a fit change) and far below the churn of a slot rebuilt
- * per render in a scrolling feed.
+ * `renderVideo` is compared by identity — and on web it is part of what a host
+ * publishes to the layer — so an unmemoised slot re-renders the surface on
+ * every render of the row it lives in, silently and only under load.
+ *
+ * Consecutive, never a lifetime total. A correctly memoised slot changes
+ * identity whenever the state it reads changes (`isWatched` on a reel slide,
+ * say), so ANY fixed lifetime total is reached eventually by a consumer with
+ * nothing to fix — and the warning's own advice, `useCallback` over the props
+ * the slot reads, is what such a consumer already wrote. Five in a row is
+ * unreachable that way: it takes five commits where nothing the slot reads
+ * changed and the slot was rebuilt anyway.
  */
 export const SLOT_IDENTITY_CHURN_LIMIT = 5;
 
+/**
+ * How long a run of {@link SLOT_IDENTITY_CHURN_LIMIT} new slots may take and
+ * still be reported (ms).
+ *
+ * "Consecutive" alone is not enough for the consumer who memoised the surface's
+ * other props as well: `memo` then skips every render where only the parent
+ * changed, so the surface commits ONLY when the slot changes and the run never
+ * breaks — with nothing to fix and, because the renders were skipped, no cost
+ * paid either.
+ *
+ * Rate is what separates them, and it is what the warning was always about. A
+ * slot rebuilt per render changes as fast as its row renders, which in a
+ * scrolling feed is five times in a fraction of a frame budget. A slot rebuilt
+ * when the state it reads changes moves at the speed of a finger, and half a
+ * second is far too short for five activations of ONE surface.
+ */
+export const SLOT_IDENTITY_CHURN_WINDOW_MS = 500;
+
 /**
  * How far a media element may sit from the box it is supposed to fill, in px,
  * before Bloom says so.

package/src/media-flight/types.ts

@@ -276,9 +276,14 @@ export interface MediaVideoSlotProps<P extends VideoPlayerLike = VideoPlayerLike
  * So the consumer may build the element instead, with Bloom deciding only what
  * it has to: which player, and a style that fills the box.
  *
- * MEMOISE IT (`useCallback`). The slot is part of what a host publishes to the
- * layer, compared by identity — a new function every render republishes every
+ * MEMOISE IT (`useCallback`), over the state the element actually reads. The
+ * slot is compared by identity — and on web it is part of what a host publishes
+ * to the layer — so a new function every render re-renders the surface every
  * render. Correct either way, wasteful if you skip it.
+ *
+ * It is expected to change when that state does; only a slot rebuilt on renders
+ * where nothing it reads changed is the mistake, and that is the only one Bloom
+ * warns about.
  */
 export type MediaVideoSlot<P extends VideoPlayerLike = VideoPlayerLike> = (
   props: MediaVideoSlotProps<P>,

package/src/tab-bar/TabBarBase.tsx

@@ -22,7 +22,14 @@ import {
   useMemo,
   type ComponentType,
 } from 'react';
-import { Pressable, StyleSheet, useWindowDimensions, View, type ViewStyle } from 'react-native';
+import {
+  Platform,
+  Pressable,
+  StyleSheet,
+  useWindowDimensions,
+  View,
+  type ViewStyle,
+} from 'react-native';
 import { Gesture, GestureDetector } from 'react-native-gesture-handler';
 import Animated, {
   Extrapolation,
@@ -260,8 +267,14 @@ function TabBarBody({
   // Scrubbing: the highlight tracks the finger 1:1 while dragging (no spring —
   // it must feel attached), haptic ticks fire on boundary crossings, and
   // navigation happens only on release. Taps are handled by a Tap gesture
-  // racing the pan — the detector consumes the bar's touches, so the inner
-  // Pressables never receive them.
+  // racing the pan.
+  //
+  // THE DETECTOR DOES NOT CONSUME THE PRESS, which this file assumed for a long
+  // time. A `Tap` gesture activates on RELEASE, by which point the inner
+  // `Pressable` has already fired `onPress`, and RNGH's cancellation of the RN
+  // responder comes too late to stop it. Measured on a Pixel 10 Pro: ONE tap
+  // produced both, ~600ms apart on a busy JS thread, so every consumer got two
+  // selections per tap. `TabBarButtonBody` is where that is resolved.
   const gesture = useMemo(() => {
     const indexAtX = (x: number, minimizedValue: number) => {
       'worklet';
@@ -544,6 +557,9 @@ interface TabBarButtonBodyProps extends TabBarButtonProps {
 }
 
 /** One tab trigger: icon + label that fades out when the bar minimizes. */
+/** Stable identity: a new array each render would re-send the actions to the OS. */
+const ACTIVATE_ACTIONS = [{ name: 'activate' as const }];
+
 function TabBarButtonBody({
   Glyph,
   item,
@@ -639,6 +655,15 @@ function TabBarButtonBody({
       aria-selected={focused}
       accessibilityLabel={item.label}
       {...pressableProps}
+      // ASSISTIVE TECHNOLOGY, on native, is the one activation the bar's gesture
+      // cannot see: TalkBack and VoiceOver activate a view without ever
+      // producing a touch, so the `Tap` gesture never runs and the selection has
+      // to come from here.
+      accessibilityActions={ACTIVATE_ACTIONS}
+      onAccessibilityAction={(event) => {
+        if (event.nativeEvent.actionName !== 'activate') return;
+        if (isFocused === undefined) bar?.selectIndex(index);
+      }}
       onPress={(event) => {
         // The bar's GestureDetector normally consumes touches; this still fires
         // for assistive-technology activation (VoiceOver) and keyboard focus.
@@ -654,10 +679,19 @@ function TabBarButtonBody({
           bar.highlightOpacity.value = withTiming(1, HIGHLIGHT_FADE);
         }
         setMinimized(minimized, 0);
-        // Controlled path only. On the focus-driven path the trigger's own
-        // `onPress` below performs the navigation, so reporting the selection
-        // here as well would navigate twice.
-        if (isFocused === undefined) bar?.selectIndex(index);
+        // Controlled path only, and NOT on Android. On the focus-driven path the
+        // trigger's own `onPress` below performs the navigation, so reporting
+        // the selection here as well would navigate twice.
+        //
+        // ANDROID IS THE ONE PLATFORM THAT DOUBLES. RNGH sets
+        // `cancelsTouchesInView` on iOS, so a recognised tap cancels this press
+        // and the gesture above is the only reporter there; react-native-web
+        // likewise routes a keyboard Enter or Space through this press and
+        // nothing else. Android cancels nothing — measured on a Pixel 10 Pro,
+        // one tap produced `PRESSABLE selectIndex(1)` AND `GESTURE tap
+        // selectIndex(1)` ~600ms apart on a busy JS thread — so there, and only
+        // there, this press stands down.
+        if (isFocused === undefined && Platform.OS !== 'android') bar?.selectIndex(index);
         onPress?.(event);
       }}
       // `Pressable`'s `style` also accepts a function of the press state; both