Add prototype signals+path-tracking implementation

.github/workflows/publish.yml

@@ -4,6 +4,17 @@ on:
   #release:
   #  types: [published]
   workflow_dispatch:
+    inputs:
+      tag:
+        description: 'NPM dist-tag (latest, alpha, beta, next)'
+        required: true
+        default: 'latest'
+        type: choice
+        options:
+          - latest
+          - next
+          - alpha
+          - beta
 
 permissions: {}
 
@@ -29,4 +40,4 @@ jobs:
           cache: 'pnpm'
       - run: pnpm install --frozen-lockfile
       - run: pnpm test
-      - run: npm publish --access public --provenance
+      - run: npm publish --access public --provenance --tag ${{ inputs.tag }}

.github/workflows/test.yml

@@ -213,8 +213,12 @@ jobs:
         run: pnpm install
 
       # Note: We currently expect "FalseCJS" failures for Node16 + `moduleResolution: "node16",
+      # `--profile node16` drops the node10 resolution check. The subpath
+      # entry points (`alternate-renderers`, `signals`) only resolve through
+      # the `exports` map, which node10 does not read, and we do not support
+      # Node 10 style resolution for them.
       - name: Run are-the-types-wrong
-        run: pnpm exec attw ./package.tgz --format table --ignore-rules false-cjs --exclude-entrypoints alternate-renderers
+        run: pnpm exec attw ./package.tgz --format table --ignore-rules false-cjs --profile node16
 
   test-published-artifact:
     name: Test Published Artifact ${{ matrix.example }}
@@ -330,7 +334,7 @@ jobs:
       fail-fast: false
       matrix:
         node: ['24.x']
-        example: ['rr-rsc-context']
+        example: ['rr-rsc-context', 'rr-tree-shaking']
     defaults:
       run:
         working-directory: ./examples/publish-ci/${{ matrix.example }}

.oxlintrc.json

@@ -47,6 +47,16 @@
       "rules": {
         "no-unused-expressions": "off"
       }
+    },
+    {
+      "files": [
+        "test/signals/diff.spec.ts",
+        "test/signals/identityArrayTracking.spec.ts",
+        "test/signals/trackingProxy.spec.ts"
+      ],
+      "rules": {
+        "no-unused-expressions": "off"
+      }
     }
   ]
 }

docs/api/Provider.md

@@ -18,6 +18,8 @@ Since any React component in a React Redux app can be connected to the store, mo
 
 The [Hooks](./hooks.md) and [`connect`](./connect.md) APIs can then access the provided store instance via React's Context mechanism.
 
+If you want to use the [`useSignalSelector`](./useSignalSelector.md) hook, use the drop-in [`<SignalProvider>`](./SignalProvider.md) replacement instead.
+
 ### Props
 
 ```ts

docs/api/SignalProvider.md

@@ -0,0 +1,82 @@
+---
+id: SignalProvider
+title: SignalProvider
+sidebar_label: SignalProvider
+hide_title: true
+description: 'API > SignalProvider: a drop-in replacement for Provider that enables signal-based selector tracking'
+---
+
+ 
+
+# `SignalProvider`
+
+_added in v9.4.0_
+
+`<SignalProvider>` is a drop-in replacement for [`<Provider>`](./Provider.md) that enables fine-grained, signal-based state tracking for the [`useSignalSelector`](./useSignalSelector.md) hook.
+
+Like `<Provider>`, it makes the Redux `store` available to any nested components. In addition, it maintains an internal graph of "path signals" that represent individual fields within the Redux state. On every dispatch, it diffs the previous and next state, and updates only the signals for the fields that actually changed. `useSignalSelector` uses that graph to re-run selectors only when a field they actually read has changed.
+
+```jsx
+import { SignalProvider } from 'react-redux'
+
+const store = createStore(rootReducer)
+
+const root = ReactDOM.createRoot(document.getElementById('root'))
+root.render(
+  <SignalProvider store={store}>
+    <App />
+  </SignalProvider>,
+)
+```
+
+:::tip
+
+All of the standard React Redux APIs - [`useSelector`](./useSelector.md), [`useDispatch`](./useDispatch.md), [`useStore`](./useStore.md), and [`connect`](./connect.md) - work unchanged inside a `<SignalProvider>`. They receive the plain Redux state and behave exactly as they do under `<Provider>`. Only components that use `useSignalSelector` opt in to the fine-grained tracking behavior.
+
+:::
+
+## API Reference
+
+### Props
+
+`SignalProvider` accepts the same props as [`<Provider>`](./Provider.md):
+
+| Name                     | Description                                                                                                                                         |
+| :----------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `store`                  | The single Redux store in your application.                                                                                                         |
+| `children`               | The top-level React elements in your component tree.                                                                                                |
+| `context?`               | An optional custom context instance, as with `<Provider>`.                                                                                          |
+| `serverState?`           | An optional server state snapshot, used during initial hydration to keep the UI output consistent with the server-generated HTML.                   |
+| `stabilityCheck?`        | Global default for the `useSelector`/`useSignalSelector` [selector stability check](./useSelector.md#selector-result-stability) (development only). |
+| `identityFunctionCheck?` | Global default for the [identity function check](./useSelector.md#identity-function-state--state-check) (development only).                         |
+
+## Usage Guide
+
+### Differences from `Provider`
+
+`<SignalProvider>` behaves like `<Provider>`, with these differences:
+
+#### The state must be a plain object
+
+The root of your Redux state must be a plain JavaScript object, because the state diffing and path tracking operate on its keys. This is reflected in the types: `SignalProvider`'s state generic is constrained to `S extends object`, where `Provider` accepts any state type.
+
+Standard Redux usage with `combineReducers` or Redux Toolkit's `configureStore` always produces a plain object root, so this only matters if your root reducer returns a primitive, a class instance, or another non-plain value. Those setups should keep using `<Provider>` and `useSelector`.
+
+#### Every dispatch runs a state diff
+
+Before notifying subscribers, `<SignalProvider>` compares the previous and next state and updates the changed path signals. This is a structural walk of the changed portions of the state, and adds some work to each dispatch in exchange for skipping selector re-runs in components. See the [`useSignalSelector` performance notes](./useSignalSelector.md#performance-characteristics) for the tradeoffs.
+
+#### The signal graph is keyed to the store
+
+Each `<SignalProvider>` owns one signal registry per store instance. Swapping the `store` prop starts over with a fresh registry, the same way `<Provider>` resets its subscriptions. Multiple `<SignalProvider>`s with different stores (via custom contexts) keep fully independent signal graphs.
+
+### When should I use `SignalProvider`?
+
+Use `<SignalProvider>` if you want to adopt [`useSignalSelector`](./useSignalSelector.md) anywhere in your app. Since all the other React Redux APIs work unchanged, it is safe to swap in at the root and migrate components incrementally.
+
+If your app does not use `useSignalSelector`, there is no benefit to `<SignalProvider>` - the per-dispatch diff adds cost without anything consuming its results. Use the standard `<Provider>`.
+
+## See Also
+
+- [`useSignalSelector`](./useSignalSelector.md): the hook that consumes the signal graph
+- [`Provider`](./Provider.md): the standard store provider

docs/api/batch.md

@@ -16,10 +16,12 @@ batch((fn: () => void))
 
 _added in v7.0.0_
 
-:::info
+:::caution Deprecated
 
 **If you're using React 18, you do not need to use the `batch` API**. React 18 automatically batches _all_ state updates, no matter where they're queued.
 
+`batch` is now a no-op that immediately runs the callback, and **will be removed in the next major version of React Redux**.
+
 :::
 
 React's `unstable_batchedUpdates()` API allows any React updates in an event loop tick to be batched together into a single render pass. React already uses this internally for its own event handler callbacks. This API is actually part of the renderer packages like ReactDOM and React Native, not the React core itself.