@yoltra/core 0.5.0 → 0.7.0

package/README.md

@@ -34,20 +34,20 @@ emit(channel, type, payload)
   │
   ├─ 0. Dedup (opt-in) ─── Skip a duplicate only when dedupWindowMs > 0 or a dedupKey is given
   │
-  │  ══ SYNCHRONOUS reduce phase — runs before emit() returns ══
+  │  ══ SYNCHRONOUS reduce phase: runs before emit() returns ══
   ├─ 1. Middleware ─── Synchronous pre-reducer hooks (return false to reject → "uncommitted" event)
-  ├─ 2. Reducers ─── Synchronous state updates, fine-grained path change detection
+  ├─ 2. Reducers ─── Every matching slice staged, then all committed under one root
   ├─ 3. Event subscribers ─── Committed/uncommitted event notifications
   ├─ 4. Coarse subscribers ─── External store listeners (useSyncExternalStore, etc.), if state changed
   │
   └─ 5. Effects ─── ASYNC side-effects, one independent task per event (keyed for O(1) lookup)
 ```
 
-The reduce phase (1–4) is **synchronous**, so `getState()` is correct the instant `emit()` returns
-— even with middleware. Effects (5) run afterward as an independent async task; the promise from
+The reduce phase (1–4) is **synchronous**, so `getState()` is correct the instant `emit()` returns,
+even with middleware. Effects (5) run afterward as an independent async task; the promise from
 `emit()` resolves when that event's effects finish. Every stage is hook-able, and
-`store.instrument()` exposes the whole flow — changed leaf paths, reduce timing, committed/rejected
-phase — to the DevTools with no `as any`. See the
+`store.instrument()` exposes the whole flow (changed leaf paths, reduce timing, committed/rejected
+phase) to the DevTools with no `as any`. See the
 [Event Pipeline Architecture](../../docs/en/design/event-queue-architecture.md) for the full model.
 
 ---
@@ -71,17 +71,17 @@ Subscribe to exact state paths using dotted notation. Supports `*` (one segment)
 or more segments) wildcards:
 
 ```typescript
-// Exact path — fires when items[0].title changes
+// Exact path: fires when items[0].title changes
 store.connect({ reducer: "todos", property: "items.0.title" }, (change) =>
   console.log("title:", change.oldValue, "→", change.newValue),
 );
 
-// Single-segment wildcard — fires when ANY item's title changes
+// Single-segment wildcard: fires when ANY item's title changes
 store.connect({ reducer: "todos", property: "items.*.title" }, (change) =>
   console.log("some title changed at", change.path),
 );
 
-// Deep wildcard — fires when anything under items changes
+// Deep wildcard: fires when anything under items changes
 store.connect({ reducer: "todos", property: "items.**" }, (change) =>
   console.log("items tree changed at", change.path),
 );
@@ -108,7 +108,7 @@ await store.emit("auth", "login", { token: "abc123" });
 store.getState().token; // "abc123"
 ```
 
-Such a slice has no property beneath it, so its changes are reported at the **slice root** —
+Such a slice has no property beneath it, so its changes are reported at the **slice root**,
 the empty path. Subscribe to it with `property: ""`:
 
 ```typescript
@@ -117,20 +117,20 @@ store.connect({ reducer: "token", property: "" }, (change) =>
 );
 ```
 
-The types know the difference. `property` on a root-value slice accepts `""` and nothing else —
-there is no key to address — and the value comes back correctly typed:
+The types know the difference. `property` on a root-value slice accepts `""` and nothing else,
+because there is no key to address, and the value comes back correctly typed:
 
 ```typescript
 const token = useAtomicProp({ reducer: "token", property: "" }); // string | null
 ```
 
-### `""` versus `"**"` — watching a whole slice
+### `""` versus `"**"`: watching a whole slice
 
 Two subscriptions sound alike and are not:
 
 | Pattern | Fires when |
 |---|---|
-| `""` | the slice's **whole value** is replaced — a primitive changes, a `Map` is rebuilt, an object slice becomes `null` |
+| `""` | the slice's **whole value** is replaced: a primitive changes, a `Map` is rebuilt, an object slice becomes `null` |
 | `"**"` | **anything** in the slice changes, at any depth. Matches the root too, since `**` matches zero segments |
 | `"*"` | one level down, exactly. Never matches the root |
 
@@ -140,7 +140,7 @@ because such a slice reports its changes at their leaves.
 
 `Map` and `Set` are compared by reference, not by entry: a reducer returning a new `Map` is a
 change, mutating one in place is not. That follows from the immutability contract rather than
-being a special case — build a new collection instead of mutating the stored one. It is also why
+being a special case. Build a new collection instead of mutating the stored one. It is also why
 they have no paths beneath them: `"byId"` is subscribable, `"byId.get"` is not, and the types
 say so.
 
@@ -169,7 +169,7 @@ type AppEM = {
   system: { init: void; shutdown: void };
 };
 
-// Match specific event keys (recommended — preserves type correlation)
+// Match specific event keys (recommended: preserves type correlation)
 const counterReducer = {
   state: { value: 0 },
   when: {
@@ -218,7 +218,7 @@ both raw functions (legacy) and `MiddlewareSpec` objects with targeting:
 ```typescript
 import type { MiddlewareSpec } from "@yoltra/core";
 
-// Targeted middleware — only runs for admin channel events
+// Targeted middleware: only runs for admin channel events
 const adminGuard: MiddlewareSpec<AppState, AppEM> = {
   when: { channel: "admin" },
   middleware: (state, event) => {
@@ -228,7 +228,7 @@ const adminGuard: MiddlewareSpec<AppState, AppEM> = {
   meta: { type: "middleware", name: "adminGuard" },
 };
 
-// Global middleware — runs for all events (synchronous: return a boolean, never a Promise)
+// Global middleware: runs for all events (synchronous: return a boolean, never a Promise)
 const logger = (state, event) => {
   console.log("Event:", event.channel, event.type);
   return true;
@@ -301,12 +301,12 @@ Subscribe to events (not state) from the view layer. Useful for notifications, a
 responding to rejected events:
 
 ```typescript
-// Committed events (default) — events that passed middleware
+// Committed events (default): events that passed middleware
 const off = store.onEvent("ui", "save", (event, getState, emit, phase) => {
   console.log("Save committed:", event.payload);
 });
 
-// Uncommitted events — events rejected by middleware
+// Uncommitted events: events rejected by middleware
 store.onEvent(
   "ui",
   "delete",
@@ -316,7 +316,17 @@ store.onEvent(
   "uncommitted",
 );
 
-// All events — both committed and uncommitted
+// Written events: state actually changed. Fires after the commit, so getState() is current.
+store.onEvent(
+  "plan",
+  "patch",
+  (event, getState) => {
+    console.log("applied:", getState().plan);
+  },
+  "written",
+);
+
+// All events: both committed and uncommitted (not written; see below)
 store.onEvent(
   "ui",
   "action",
@@ -327,11 +337,190 @@ store.onEvent(
 );
 ```
 
+`committed` means **not vetoed**, and always has: it fires for every event middleware let through,
+whether or not a reducer wrote anything, including every event in a store with no reducers at
+all. `written` is the stricter fact, added rather than substituted, so toasts and analytics keep
+working unchanged. `all` stays `committed | uncommitted`; folding `written` in would hand existing
+subscribers a second notification per event.
+
+---
+
+## Commits are atomic across slices
+
+An event that touches several slices writes all of them, then notifies. Nothing observes a
+half-applied event. A subscriber to one slice reading `getState()` sees every other slice of the
+same event already applied.
+
+That matters most where a change is used as a signal to re-read, which is what the React hooks do.
+
+---
+
+## Refusing a write
+
+A reducer returns `Rejected(reason)` instead of state to decline. **The whole event is rejected**:
+no slice writes, no change notification fires, and the caller is told why.
+
+```typescript
+import { createStore, Rejected } from "@yoltra/core";
+
+const store = createStore({
+  name: "plan",
+  reducer: {
+    plan: {
+      state: { steps: [], version: 1 },
+      when: { keys: [["plan", "patch"]] },
+      reducer: (state, event) =>
+        event.payload.expectedVersion === state.version
+          ? { ...state, steps: event.payload.steps, version: state.version + 1 }
+          : Rejected(`stale write: expected v${event.payload.expectedVersion}, have v${state.version}`),
+    },
+  },
+  onRejected: (rejection, event, slice) => metrics.increment("write.refused", { slice }),
+});
+
+const result = await store.emit("plan", "patch", { steps, expectedVersion: 1 });
+
+result.committed; // true: middleware allowed it
+result.written; // false: nothing was written
+result.rejected?.reason; // "stale write: expected v1, have v3"
+```
+
+Refusing is **not** the same as returning the state unchanged, which is indistinguishable from
+"this event did not concern me". It is also not the same as throwing: a reducer that throws has a
+bug, so its slice is isolated and every other slice still commits, while a reducer that refuses
+has made a decision and the whole event yields to it.
+
+`emit` resolves to an `EmitResult` once effects have run:
+
+| | |
+|---|---|
+| `committed` | middleware did not veto |
+| `written` | a reducer actually changed state |
+| `rejected` | present when a reducer refused, carrying `reason` |
+
+---
+
+## Request and reply: `store.call()`
+
+Every event-bus consumer eventually writes request/reply by hand: mint an id, subscribe, match,
+time out, unsubscribe. It is about eighty lines and it has the same two bugs every time: the
+subscription outlives the call, and a responder that forgets to echo the id produces a timeout
+with nothing to point at.
+
+```typescript
+const res = await store.call("rpc", "ask", { q: "who?" }, { reply: ["rpc", "answer"] });
+res.payload.text;
+```
+
+The responder does nothing special. It replies through the `emit` it was handed, and the store's
+causal stamp correlates the two, and **there is no id to mint, echo, or forget**:
+
+```typescript
+store.registerEffect({
+  when: { keys: [["rpc", "ask"]] },
+  effect: async (event, _get, emit) => {
+    await emit("rpc", "answer", await lookup(event.payload.q));
+  },
+});
+```
+
+### A call resolves to the event, not the payload
+
+Because a caller often cannot know *which* reply it will get. `reply` names the **terminal**
+types, and the event carries the discriminant:
+
+```typescript
+const res = await store.call("rpc", "ask", { q }, { reply: ["rpc", ["answer", "error"]] });
+
+switch (res.type) {
+  case "answer": return res.payload.text;
+  case "error": throw new Error(res.payload.reason);
+}
+```
+
+### Progress streams, and the producer waits
+
+Any correlated event that is **not** terminal is progress. Iterate the call to consume it:
+
+```typescript
+const call = store.call("job", "start", { id }, {
+  reply: ["job", "done"],
+  highWaterMark: 4,
+});
+
+for await (const step of call) await render(step.payload);
+const { payload } = await call;
+```
+
+The backpressure is real, not a buffer with a limit. `emit` resolves only once its effects have
+run, and the collector is an effect that does not return until the consumer has taken the item,
+so a responder writing `await emit("job", "tick", chunk)` is **paced by the reader**:
+
+```typescript
+effect: async (_event, _get, emit) => {
+  for (const chunk of chunks) {
+    await emit("job", "tick", chunk); // waits here while the consumer is behind
+  }
+  await emit("job", "done", { ok: true });
+}
+```
+
+Backpressure engages **once you begin iterating**. A call that is only awaited never pulls, so
+blocking its producer would deadlock the call itself: progress nobody reads would stop the
+terminal event from ever being sent. Un-iterated progress therefore buffers to `highWaterMark`
+and is then counted on `call.dropped` rather than blocking.
+
+### Giving up
+
+| | |
+|---|---|
+| `timeoutMs` | **Idle**, not total: every correlated event resets it, progress included. A job that streams for two minutes will not fail a thirty-second call. Default 30s. |
+| `signal` | An `AbortSignal`, for a real deadline or a cancelled action. |
+| `call.cancel(reason)` | Stops listening and settles. Safe to call twice. |
+
+However a call ends, whether resolved, timed out or aborted, the subscription is removed and any producer
+parked on backpressure is released. A wedged responder is worse than the unbounded buffer this
+replaced.
+
+## Reading a value as you subscribe
+
+`connect` starts at "from now on", so a subscriber's first read had to repeat the path elsewhere:
+the same path in two places, free to drift:
+
+```typescript
+store.connect({ reducer: "todos", property: "items.0.title" }, render, { immediate: true });
+```
+
+The synthetic first change has `oldValue: undefined` and **no provenance**, because no event
+caused it. For a wildcard pattern, which has no single current value, the slice root is delivered
+with `path: ""`.
+
+React does not need this: `useSyncExternalStore` already reads a snapshot on mount.
+
+---
+
+## Where a change came from
+
+A `Change` names the event that caused it, so a subscriber no longer has to mirror the cause into
+state and keep it in two places:
+
+```typescript
+store.connect({ reducer: "orders", property: "status" }, (change) => {
+  audit.record(change.path, change.newValue, {
+    causedBy: change.eventId,
+    via: `${change.channel}/${change.type}`,
+  });
+});
+```
+
+Provenance is **absent** when no event caused the change: a DevTools time-travel jump, or the
+`immediate` delivery above. Absence is the signal, rather than a fabricated id.
+
 ---
 
 ## Event Deduplication (opt-in)
 
-Deduplication is **off by default** — Yoltra never silently drops legitimate rapid-fire identical
+Deduplication is **off by default**. Yoltra never silently drops legitimate rapid-fire identical
 events (double-clicks, repeated `+1`). Opt in only when you actually want coalescing:
 
 ```typescript
@@ -344,12 +533,63 @@ const store = createStore({
   dedupWindowMs: 100, // default: 0 (disabled)
 });
 
-// Identity-based: dedupe by an explicit key — e.g. a React Strict Mode double-invoke in an effect.
+// Identity-based: dedupe by an explicit key, e.g. a React Strict Mode double-invoke in an effect.
 await store.emit("analytics", "pageView", { page }, { dedupKey: `pageView:${page}` });
 ```
 
 ---
 
+## Cascade protection (on by default)
+
+Two consumers wired into each other, whether a subscriber that emits what its own reducer answers or
+two slices that answer each other's events, produce an event chain with no end. The reduce queue
+drains **synchronously**, so that is not a slow program: it is a frozen tab, or a pinned core,
+with no error and no stack to point at.
+
+Every event therefore carries its causal position, and the store refuses to extend a chain past a
+ceiling:
+
+```typescript
+const store = createStore({
+  name: "app",
+  reducer: { ... },
+
+  // Defaults to 64. Bounded whether or not you configure it. A failure mode this bad
+  // should not require configuration to avoid. Set Infinity to opt out and own it.
+  maxReduceDepth: 64,
+
+  onCascade: ({ event, depth, chain }) => {
+    report(`cascade at ${event.channel}/${event.type}, depth ${depth}`, chain);
+  },
+});
+```
+
+An event emitted while another is being handled is one deeper than its cause, and carries
+`parentId` and `depth` so the cycle is legible after the fact:
+
+```typescript
+store.onEvent("plan", "patch", (event) => {
+  event.depth;     // 0 for an event emitted by application code
+  event.parentId;  // undefined at depth 0; the causing event's id below it
+});
+```
+
+Both fields are **absent** on a root event rather than present as `0`/`undefined`, so events your
+application emits stay byte-identical to before this existed.
+
+Breaching does not throw. The offending emit is refused, everything already committed stands, and
+`onCascade` (plus a console error) names it. A throw would surface in whichever subscriber or
+effect happened to be emitting, which is the same unattributable failure the ceiling exists to
+prevent.
+
+**A wide burst is not a cascade.** One event whose subscriber fans out to five hundred siblings
+is a legitimate shape; depth is what separates it from a cycle, and a plain loop of `store.emit`
+never accumulates depth at all, because each call drains to completion before the next, so every one is
+a root. `maxTransitionsPerDrain` bounds burst *width* and is off by default for that reason; the
+event that starts a drain is never refused by it.
+
+---
+
 ## Dynamic Reducers
 
 Add or remove reducer slices at runtime:
@@ -399,13 +639,13 @@ if (import.meta.hot) {
 
 ### State is synchronous; `await` only for effects
 
-The reduce phase is synchronous, so state reflects your event the moment `emit()` returns — no
+The reduce phase is synchronous, so state reflects your event the moment `emit()` returns, with no
 `await` needed to read it back. Await `emit()` when you also want _this event's_ effects to have
 finished:
 
 ```typescript
 emit("todo", "add", todo);
-store.getState(); // Already reflects the new todo — no await required
+store.getState(); // Already reflects the new todo. No await required
 
 await emit("todo", "save", todo); // resolves once save's effects complete
 ```
@@ -509,7 +749,7 @@ that never happened.
 
 **Nothing throws on boot.** A missing, unparseable or unmigratable payload falls back to your
 declared defaults and reports through `onError`. A store that will not start because storage
-holds stale JSON is worse than one that starts fresh — and a full disk should not take down a
+holds stale JSON is worse than one that starts fresh, and a full disk should not take down a
 page, so write failures are reported the same way rather than raised.
 
 **Version mismatches are refused, not trusted.** Reducers change, and a snapshot written
@@ -527,7 +767,7 @@ For a server render, `dehydrate(store, { version })` produces the payload and
 ## Lists that reorder
 
 Path notification is positional for arrays. `items.0.title` names a *slot*, not a thing, so
-`unshift`, `splice(0, 1)` and `sort` move nearly every element into a different slot — and the
+`unshift`, `splice(0, 1)` and `sort` move nearly every element into a different slot, and the
 diff correctly reports that nearly every leaf changed. Inserting one row at the front of a
 thousand wakes a thousand subscribers.
 
@@ -550,7 +790,7 @@ todos.idsPath;                 // "ids"
 `entities.abc.title` survives insert, remove and reorder. A list container subscribes to `ids`
 and reorders its children; rows subscribe to their own entity and stay asleep through a sort.
 
-`ids` is still an array, so a reorder still reports `ids.0`, `ids.1` and so on — that cost is
+`ids` is still an array, so a reorder still reports `ids.0`, `ids.1` and so on. That cost is
 confined, not removed. What you get is cost proportional to what actually changed.
 
 For a small list that only ever grows at the end, `items.0.title` is fine and simpler. The
@@ -563,8 +803,8 @@ normalised, and the array reports roughly a thousand changed paths against two.
 case the adapter is for.
 
 A single-field update runs the other way: 20 µs for the array against 470 µs normalised.
-`detectChangedProps` indexes an array but enumerates an object's keys — building two key
-arrays and a `Set` per comparison — so a wide entity map is more expensive to walk even when
+`detectChangedProps` indexes an array but enumerates an object's keys, building two key
+arrays and a `Set` per comparison, so a wide entity map is more expensive to walk even when
 almost nothing in it moved. The numbers are in `benchmarks/`, and closing that gap is tracked
 work rather than a property of normalising as such.
 
@@ -573,55 +813,69 @@ individual fields edited is better off as an array today.
 
 ## Performance
 
-| Metric             | Value                                     |
-| ------------------ | ----------------------------------------- |
-| **Bundle size**    | 6.7 KB for the store (minified + gzipped) |
-| **Tree-shakeable** | Yes (ES modules)                          |
-| **Dependencies**   | Zero                                      |
-| **TypeScript**     | Full type definitions included            |
+| Metric             | Value                                  |
+| ------------------ | -------------------------------------- |
+| **Bundle size**    | Measured every build, see table below |
+| **Tree-shakeable** | Yes (ES modules)                       |
+| **Dependencies**   | Zero                                   |
+| **TypeScript**     | Full type definitions included         |
 
 Bundle size is checked, not asserted: `rush size` bundles the package the way a consumer
-would — tree-shaken, minified, gzipped — and fails when it exceeds the budget declared in
-`package.json`.
+would (tree-shaken, minified, gzipped) and fails when it exceeds the budget declared in
+`package.json`. The table below is written by that same check, so it cannot drift from what
+was measured; editing it by hand fails CI.
 
 The number that matters is what you import, not what the package exports:
 
-| Import                              | Size   |
-| ----------------------------------- | ------ |
-| `{ createStore }`                   | 6.7 KB |
-| `{ createStore, hydrate, persist }` | 8.2 KB |
-| everything                          | 9.5 KB |
-
-Persistence and the entity adapter cost nothing to anyone who does not import them — the
-first row has not moved as either was added, which is the tree-shaking claim being checked
-rather than repeated. The last row is a growth tripwire; `import * as all` is not something
-anybody writes.
+<!-- size-table:start -->
+| Import | Size | Budget |
+| --- | --- | --- |
+| `{ createStore }` | 8.3 KB | 14 KB |
+| `{ createStore, hydrate, persist }` | 9.7 KB | 16 KB |
+| everything | 11.2 KB | 18 KB |
+<!-- size-table:end -->
+
+These are **production** figures: what you ship once your bundler defines
+`NODE_ENV=production` and the development-only guards drop out. The budget column is the
+ceiling `rush size` enforces, and it is checked against a development build instead, which is
+the larger of the two: dev-only code cannot grow unnoticed just because it never reaches a
+user. So the headroom implied here is deliberately conservative.
+
+The **gap between rows** is the tree-shaking claim, and it is what to watch: persistence adds
+1.5 KB to the people who import it and nothing to anyone else, and the whole barrel is 2.9 KB
+past the store. The last row is a growth tripwire; `import * as all` is not something anybody
+writes.
+
+The first row moves only when the store itself grows, and it has: bounding cascades, staging
+commits so they apply atomically, and `store.call()` are all store machinery rather than
+opt-in modules, so they are paid by everyone. That is the honest trade for a default that
+stops a runaway from hanging the tab.
 
 ---
 
 ## Documentation
 
-- **[yoltra Root README](../../README.md)** — Overview and
+- **[yoltra Root README](../../README.md)**: Overview and
   quick start
-- **[@yoltra/react](../react/README.md)** —
+- **[@yoltra/react](../react/README.md)**:
   React hooks and Suspense
-- **[Quick Start Guide](https://github.com/yoltra/yoltra/blob/main/docs/en/QUICK_START_GUIDE.md)**
-  — Five steps to a working app
-- **[Event Queue Architecture](https://github.com/yoltra/yoltra/blob/main/docs/en/design/event-queue-architecture.md)**
-  — Technical deep-dive
-- **[Library Comparison](https://github.com/yoltra/yoltra/blob/main/docs/en/design/state-management-library-comparison.md)**
-  — Architectural comparison
+- **[Quick Start Guide](https://github.com/yoltra/yoltra/blob/main/docs/en/QUICK_START_GUIDE.md)**:
+  Five steps to a working app
+- **[Event Queue Architecture](https://github.com/yoltra/yoltra/blob/main/docs/en/design/event-queue-architecture.md)**:
+  Technical deep-dive
+- **[Library Comparison](https://github.com/yoltra/yoltra/blob/main/docs/en/design/state-management-library-comparison.md)**:
+  Architectural comparison
 
 ---
 
 ## Examples
 
-- **[Todo App](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-in-react)** — Full
+- **[Todo App](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-in-react)**: Full
   CRUD with performance profiling · [▶ Open the live demo](https://yoltra.dev/en/demos/in-react)
-- **[Kinetic Logo](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-kinetic-logo)**
-  — 3000 circles with physics simulation · [▶ Open the live demo](https://yoltra.dev/en/demos/kinetic-logo)
-- **[Next.js Integration](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-in-nextjs)**
-  — Pages Router, client-side state + theme switcher · [▶ Open the live demo](https://yoltra.dev/en/demos/in-nextjs)
+- **[Kinetic Logo](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-kinetic-logo)**:
+  3000 circles with physics simulation · [▶ Open the live demo](https://yoltra.dev/en/demos/kinetic-logo)
+- **[Next.js Integration](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-in-nextjs)**:
+  Pages Router, client-side state + theme switcher · [▶ Open the live demo](https://yoltra.dev/en/demos/in-nextjs)
 
 ---
 
@@ -634,10 +888,10 @@ anybody writes.
 
 ## Status
 
-**Release Candidate** — APIs are stable, used in production, minor changes possible before v1.0.
+**Release Candidate**. APIs are stable, used in production, minor changes possible before v1.0.
 
 ---
 
 ## License
 
-**MIT** — Free to use in commercial and open-source projects.
+**MIT**. Free to use in commercial and open-source projects.

package/dist/types/index.d.ts

@@ -9,10 +9,15 @@ export { EventBus } from './eventBus/EventBus.js';
 export { LooseEventBus } from './eventBus/LooseEventBus.js';
 export { Reducer } from './reducer/Reducer.js';
 export { Store, createStore, typedEvents } from './store/Store.js';
+export { Rejected, isRejected } from './store/rejection.js';
+export { CallAbortedError, CallTimeoutError } from './store/call.js';
+export type { CallHandle, CallOptions, ReplySpec } from './store/call.js';
+export type { Rejection } from './store/rejection.js';
 export { detectChangedProps } from './utils/detectChangedProps.js';
 export { freezeState } from './utils/immutability.js';
+export type { AliasWatch } from './utils/immutability.js';
 export { eventKeys } from './types.js';
-export type { EventMapBase, EventKey, Event, EventUnion, Change, Emit, EmitOptions, EventMeta, InstrumentedEvent, InstrumentationObserver, Unsubscribe, StoreSpec, StoreInstance, ReducerSpec, ReducerFunction, ReducersMapAny, StateFromReducers, EMFromReducersStrict, EffectSpec, EffectFunction, MiddlewareFunction, MiddlewareSpec, MiddlewareInput, DeepReadonly, DeepRO, Primitive, RootValue, Path, PathValue, WithGlob, Dotted, EventPhase, EventSubscriptionHandler, NarrowedEventHandler, When, EventFromWhen, EventConsumerType, EventConsumerMeta, } from './types.js';
+export type { EventMapBase, EventKey, Event, EventUnion, Change, Emit, EmitOptions, EmitResult, ConnectOptions, EventMeta, InstrumentedEvent, CascadeInfo, InstrumentationObserver, Unsubscribe, StoreSpec, StoreInstance, ReducerSpec, ReducerFunction, ReducersMapAny, StateFromReducers, EMFromReducersStrict, EffectSpec, EffectFunction, MiddlewareFunction, MiddlewareSpec, MiddlewareInput, DeepReadonly, DeepRO, Primitive, RootValue, Path, PathValue, WithGlob, Dotted, EventPhase, NotifiedPhase, EventSubscriptionHandler, NarrowedEventHandler, When, EventFromWhen, EventConsumerType, EventConsumerMeta, } from './types.js';
 export { createEntityAdapter } from './entity/entityAdapter.js';
 export type { EntityAdapter, EntityAdapterOptions, EntityId, EntityState, EntityUpdate, } from './entity/entityAdapter.js';
 export { decodeState, encodeState, encodeStateBounded } from './serialize/codec.js';

package/dist/types/persistence/persist.d.ts

@@ -84,10 +84,6 @@ export interface Hydration {
 export declare function hydrate(options: PersistOptions & {
     readonly source?: string;
 }): Promise<Hydration>;
-/** A reducer spec, as far as hydration cares: something carrying an initial `state`. */
-interface HasState {
-    state: unknown;
-}
 /**
  * Replaces each reducer's initial state with what was restored for it.
  *
@@ -97,7 +93,9 @@ interface HasState {
  *
  * @public
  */
-export declare function withHydration<R extends Record<string, HasState>>(reducers: R, hydration: Hydration): R;
+export declare function withHydration<R extends Record<string, {
+    state: unknown;
+}>>(reducers: R, hydration: Hydration): R;
 /** The store surface persistence needs, which is two methods wide. */
 export interface PersistableStore {
     getState(): unknown;
@@ -123,4 +121,3 @@ export declare function persist(store: PersistableStore, options: PersistOptions
  * @public
  */
 export declare function dehydrate(store: Pick<PersistableStore, "getState">, options: Pick<PersistOptions, "version" | "slices">): string;
-export {};

package/dist/types/reducer/Reducer.d.ts

@@ -1,4 +1,5 @@
 import { EventMapBase, EventUnion, ReducerFunction } from '../types.js';
+import { Rejection } from '../store/rejection.js';
 /**
  * Thin wrapper around a pure reducer function (stateful event consumer):
  * given a state `S` and an event (from {@link EventUnion | `EventUnion<EM>`}),
@@ -68,7 +69,7 @@ export declare class Reducer<S, EM extends EventMapBase = EventMapBase> {
      *
      * @param state  - Current state.
      * @param event - An event drawn from {@link EventUnion | `EventUnion<EM>`}.
-     * @returns The next state produced by the underlying reducer function.
+     * @returns The next state, or a {@link Rejection} if the reducer refused the write.
      *
      * @example
      * ```ts
@@ -77,5 +78,5 @@ export declare class Reducer<S, EM extends EventMapBase = EventMapBase> {
      *
      * @public
      */
-    reduce(state: S, event: EventUnion<EM>): S;
+    reduce(state: S, event: EventUnion<EM>): S | Rejection;
 }