@braidlabs/angular-data 0.1.1

package/types/braidlabs-angular-data.d.ts

@@ -0,0 +1,624 @@
+import * as i0 from '@angular/core';
+import { Signal, InjectionToken, EnvironmentProviders } from '@angular/core';
+import { QueuedEntry, OptimisticOverlay, RecordDriver } from '@braidlabs/data';
+
+/**
+ * Entity identity.
+ *
+ * The gap this closes: `httpResource()` and friends are *per-call* caches. Two
+ * requests that return the same record produce two independent copies, and
+ * updating one leaves the other stale. Deduplicating them requires knowing that
+ * both payloads describe the same thing — which requires a declared identity.
+ */
+interface EntityType<T> {
+    /** Stable name, used for store partitioning and tag generation. */
+    readonly name: string;
+    /** Extracts the primary key. Must be stable and collision-free per type. */
+    readonly key: (value: T) => string;
+}
+interface EntityDefinition<T> {
+    readonly name: string;
+    readonly key: (value: T) => string;
+}
+/**
+ * Declares an entity type.
+ *
+ * ```ts
+ * export const Bulletin = entity<Bulletin>({ name: 'bulletin', key: (b) => b.id });
+ * ```
+ *
+ * Declare each type once and export it — identity is only useful if every
+ * query and mutation agrees on it.
+ */
+declare function entity<T>(definition: EntityDefinition<T>): EntityType<T>;
+/** Tag helpers, so invalidation reads the same way everywhere. */
+declare const tag: {
+    /** A single record: `bulletin#42`. */
+    readonly entity: <T>(type: EntityType<T>, id: string) => string;
+    /** Every record of a type: `bulletin#*`. */
+    readonly all: <T>(type: EntityType<T>) => string;
+    /** An arbitrary named collection or view. */
+    readonly collection: (name: string) => string;
+};
+
+/**
+ * A batch of writes that can be rolled back wholesale.
+ *
+ * Optimistic updates need this: the write happens before the server has agreed,
+ * so a failure must restore precisely what was there — not "roughly re-fetch".
+ */
+interface StoreTransaction {
+    upsert<T>(type: EntityType<T>, values: T | readonly T[]): void;
+    patch<T>(type: EntityType<T>, id: string, partial: Partial<T>): void;
+    remove<T>(type: EntityType<T>, id: string): void;
+}
+declare class EntityStore {
+    private readonly state;
+    private readonly pending;
+    /**
+     * Memoized per `type#id`. Without this, calling `select()` inside a template
+     * would mint a fresh computed on every change-detection pass — a subtle and
+     * expensive footgun.
+     */
+    private readonly selectCache;
+    private readonly allCache;
+    /** A single record as this page shows it: confirmed, with any pending write applied. */
+    select<T>(type: EntityType<T>, id: string): Signal<T | undefined>;
+    /**
+     * Every record of a type, in insertion order, with pending writes applied.
+     *
+     * A pending record nothing has confirmed yet still appears, and a pending removal does not: a
+     * list that omits what the user just created, or keeps what they just deleted, is the same bug
+     * seen from either end.
+     */
+    selectAll<T>(type: EntityType<T>): Signal<readonly T[]>;
+    /**
+     * A filtered view. Not memoized by predicate — call it once and keep the
+     * result, as you would any other `computed`.
+     */
+    query<T>(type: EntityType<T>, predicate: (value: T) => boolean): Signal<readonly T[]>;
+    /**
+     * Reads a record without subscribing. For use inside effects and handlers.
+     *
+     * The same value `select` would give, pending writes included — a read that disagrees with the
+     * subscribed read depending on which one you happened to call is a trap, not an optimization.
+     * {@link peekConfirmed} is the one that skips the overlay.
+     */
+    peek<T>(type: EntityType<T>, id: string): T | undefined;
+    /**
+     * The record as the server last reported it, ignoring anything queued.
+     *
+     * What a conflict is measured against: "the server disagreed with you" is a claim about the
+     * prediction, so comparing against a value that already includes the prediction would answer a
+     * different question.
+     */
+    peekConfirmed<T>(type: EntityType<T>, id: string): T | undefined;
+    upsert<T>(type: EntityType<T>, values: T | readonly T[]): void;
+    patch<T>(type: EntityType<T>, id: string, partial: Partial<T>): void;
+    remove<T>(type: EntityType<T>, id: string): void;
+    /** Empties a type, or the whole store. Mainly for sign-out and tests. */
+    clear<T>(type?: EntityType<T>): void;
+    /**
+     * Applies writes that can be undone as a unit.
+     *
+     * ```ts
+     * const tx = store.transaction();
+     * tx.apply((t) => t.patch(Bulletin, id, { status: 'published' }));
+     * // …server says no…
+     * tx.rollback();
+     * ```
+     */
+    transaction(): {
+        apply(fn: (tx: StoreTransaction) => void): void;
+        rollback(): void;
+        committed: boolean;
+    };
+    /** `confirmed ⊕ pending` for one record. The single place the two halves meet. */
+    private view;
+    private toWrites;
+    /**
+     * Single write path, so every mutation produces exactly one signal
+     * notification regardless of how many records it touched.
+     */
+    private applyWrites;
+    static ɵfac: i0.ɵɵFactoryDeclaration<EntityStore, never>;
+    static ɵprov: i0.ɵɵInjectableDeclaration<EntityStore>;
+}
+
+/**
+ * The optimistic overlay: what the queue predicts, applied over the confirmed graph.
+ *
+ *     view(record) = confirmed(record) ⊕ pending(record)
+ *
+ * The important word is *derived*. This used to be an apply-then-undo: a write patched the store,
+ * an undo log remembered the previous values, and a failure restored them. Two things went wrong
+ * with that, and both are the kind of bug nobody reports as one:
+ *
+ * 1. **The overlay and the queue could disagree.** A queued mutation lives in storage; its
+ *    optimistic effect lived in memory. Reload the page and the work was still queued while the
+ *    screen showed the old value — the user's edit apparently lost, then reappearing later when the
+ *    queue drained.
+ * 2. **Only the app that wrote could see it.** The queue is shared per origin; an undo log is not.
+ *
+ * Deriving fixes both at once. Rollback becomes deleting an entry, a reload rebuilds the overlay
+ * from the queue, and another app's unsent edits show up here because they are in the same store.
+ */
+/** One record's worth of prediction, in the entity store's terms. */
+interface EntityOverlay {
+    readonly typeName: string;
+    readonly id: string;
+    /** Applied over the confirmed record. Empty for a removal. */
+    readonly patch: Record<string, unknown>;
+    /** True when the write deletes the record — absence a patch cannot express. */
+    readonly removed?: boolean;
+}
+declare class PendingWrites {
+    private readonly groups;
+    /** Every pending overlay on the page, in the order the writes were made. */
+    readonly overlays: Signal<readonly EntityOverlay[]>;
+    /** Whether anything on screen is showing work the server has not confirmed. */
+    readonly hasPending: Signal<boolean>;
+    /**
+     * Records a write's prediction.
+     *
+     * Applied synchronously, before the entry reaches storage: a UI that waits for IndexedDB to show
+     * what the user just typed is a UI that flickers. Storage remains the truth — `syncFromQueue`
+     * replaces this the moment the queue is next read.
+     */
+    add(id: string, overlays: readonly EntityOverlay[], options: {
+        durable: boolean;
+    }): void;
+    /** Drops a group: a confirmation, or a rollback. There is no difference at this level. */
+    settle(id: string): void;
+    /** Re-keys a group once its entry id is known, so the queue's copy replaces the same group. */
+    rename(from: string, to: string): void;
+    /**
+     * Rebuilds every durable group from the queue.
+     *
+     * This is the derivation. Called on every outbox refresh — including the one after rehydrating
+     * from storage, which is how a reload gets the overlay back without anything in memory having
+     * survived, and how one app comes to show another's unsent edits.
+     */
+    syncFromQueue(entries: readonly QueuedEntry[]): void;
+    /** Sign-out, and tests. */
+    clear(): void;
+    static ɵfac: i0.ɵɵFactoryDeclaration<PendingWrites, never>;
+    static ɵprov: i0.ɵɵInjectableDeclaration<PendingWrites>;
+}
+/** `bulletin#42` — the same key `tag.entity` produces, so one write's tag and overlay agree. */
+declare function overlayKey(typeName: string, id: string): string;
+declare function toOutboxOverlay(overlay: EntityOverlay): OptimisticOverlay;
+/**
+ * Splits at the *first* `#`, because an id may contain one and a type name may not.
+ */
+declare function fromOutboxOverlay(overlay: OptimisticOverlay): EntityOverlay;
+/** Applies the overlays for one record, in order. `undefined` means pending removal. */
+declare function applyOverlays<T>(confirmed: T | undefined, overlays: readonly EntityOverlay[]): T | undefined;
+/**
+ * Runs an `optimistic(tx, input)` callback against a transaction that **records** rather than
+ * writes, turning the callback into overlay data.
+ *
+ * This is what lets the existing config surface stay exactly as it is while the mechanism
+ * underneath changes: `tx.patch(Bulletin, id, { status: 'published' })` describes a patch perfectly
+ * well, and a closure was never the part that mattered — it just happened to be how the description
+ * was expressed. Recording it makes the same description survive a reload, which the closure could
+ * never do.
+ */
+interface RecordedWrites {
+    readonly overlays: EntityOverlay[];
+    /**
+     * The entity types the callback named, by name.
+     *
+     * Kept beside the overlays rather than inside them because a type carries a `key` function, and a
+     * function cannot be persisted — the overlays go to storage, this map stays in the closure that is
+     * waiting on the server.
+     */
+    readonly types: Map<string, EntityType<unknown>>;
+}
+declare function recordOverlays(apply: (tx: StoreTransaction) => void): RecordedWrites;
+
+/**
+ * Tag-based invalidation.
+ *
+ * Tags rather than TTLs, because a time-to-live is a guess about when data went
+ * stale, whereas a mutation *knows*. `bulletin#42` and `bulletins` are claims
+ * about what a query depends on; invalidating a tag re-runs exactly the queries
+ * that said they cared.
+ *
+ * Wildcards are supported in one direction only: invalidating `bulletin#*`
+ * matches every `bulletin#…` subscriber. A subscriber may also register the
+ * wildcard itself, in which case any invalidation of that type reaches it.
+ */
+declare class CacheRegistry {
+    private readonly subscribers;
+    /**
+     * Registers interest in a set of tags. Returns a disposer.
+     *
+     * Tags are supplied as a getter and re-read on each invalidation, so a query
+     * whose tags depend on signals (a route param, a filter) stays correct
+     * without having to re-subscribe.
+     */
+    subscribe(getTags: () => readonly string[], notify: () => void): () => void;
+    /**
+     * Marks tags stale, notifying every matching subscriber.
+     *
+     * Notification is synchronous but failure-isolated: one subscriber throwing
+     * must not prevent the others from refreshing.
+     */
+    invalidate(...tags: readonly string[]): void;
+    /** Subscriber count. Diagnostics and tests only. */
+    get size(): number;
+    static ɵfac: i0.ɵɵFactoryDeclaration<CacheRegistry, never>;
+    static ɵprov: i0.ɵɵInjectableDeclaration<CacheRegistry>;
+}
+/**
+ * `bulletin#*` matches `bulletin#42` in either position, so a mutation can
+ * invalidate a whole type without enumerating ids, and a list query can
+ * subscribe to a whole type without knowing which ids it will receive.
+ */
+declare function tagsMatch(a: string, b: string): boolean;
+
+interface DataOptions {
+    /**
+     * Where the outbox is stored. Shared across every app on the origin.
+     *
+     * A record-oriented driver rather than a key/value store, and that is the correctness fix: the
+     * queue used to live under a single key, so appending meant read-modify-write and two apps
+     * interleaving lost each other's entries.
+     */
+    readonly driver: RecordDriver;
+    /**
+     * Which application this is, stamped onto every entry it queues.
+     *
+     * The store is shared, so ownership is what keeps one app from acting on another's queued work.
+     * Only the owner replays an entry; everyone else leaves it alone.
+     */
+    readonly owner: string;
+    /** Attempts before a queued entry is abandoned. Default 5. */
+    readonly maxOutboxAttempts: number;
+    /**
+     * Reports outbox trouble: an abandoned entry, a mutation this build no longer has, a failed write.
+     *
+     * Silent by default, but wiring it to telemetry is how you find out that users are losing queued
+     * work — the failure is otherwise invisible, because the user already navigated away believing it
+     * saved.
+     */
+    readonly onOutboxError?: (message: string, detail?: unknown) => void;
+    /** Flush the outbox when the browser reports it is back online. Default true. */
+    readonly flushOnReconnect: boolean;
+    readonly buildId?: string;
+}
+declare const DATA_OPTIONS: InjectionToken<DataOptions>;
+interface DataOptionsInput {
+    /**
+     * Identifies this application in the shared outbox. **Required when persisting.**
+     *
+     * Not defaulted, deliberately. A default would be the same string in every app on the page, which
+     * is precisely the collision ownership exists to prevent — and it would fail silently, in
+     * production, on someone's unsent work.
+     */
+    readonly owner?: string;
+    /** Supply storage directly. Overrides `persistOutbox`. */
+    readonly driver?: RecordDriver;
+    readonly maxOutboxAttempts?: number;
+    readonly onOutboxError?: DataOptions['onOutboxError'];
+    readonly flushOnReconnect?: boolean;
+    /**
+     * Persist the outbox in IndexedDB, so queued work survives a reload.
+     *
+     * Off by default: queued work is then lost on reload, which is only appropriate when every
+     * mutation is fire-and-forget.
+     */
+    readonly persistOutbox?: boolean;
+    /** Stamped onto persisted envelopes for attribution. */
+    readonly buildId?: string;
+    /** Database name when persisting. Defaults to `skew-data`. */
+    readonly database?: string;
+    /**
+     * Extra collections to create alongside the outbox.
+     *
+     * Declared up front because IndexedDB can only create object stores during a version upgrade —
+     * a collection used but not declared fails at the first read, not at configuration time.
+     */
+    readonly collections?: readonly string[];
+}
+declare const OUTBOX_COLLECTION = "outbox";
+declare function resolveDataOptions(input?: DataOptionsInput): DataOptions;
+
+/**
+ * The durable mutation outbox, as an Angular service over `@braidlabs/data`.
+ *
+ * This is the piece that cannot be built with in-flight request machinery. A mutation queued while
+ * offline has to survive a page reload — and after a reload there is no pending `Promise` to retry,
+ * no `HttpRequest` to intercept, and no closure left alive. Only something persisted can be
+ * replayed.
+ *
+ * Which forces one API constraint: an outbox mutation must have a stable `id`, because the
+ * *operation* is a closure and closures do not serialise. On replay we look the operation up by id.
+ *
+ * **The store is shared and the entries are owned.** Persistence lives in `@braidlabs/data`, one
+ * record per entry, in a store every app on the origin reads. This service replays only what it
+ * owns. Previously the queue was a single blob under one key, so a second app overwrote the first's
+ * and then dropped its entries for having no registered runner — silently, unless `onOutboxError`
+ * happened to be wired.
+ */
+/** A queued entry as this app sees it. */
+type OutboxEntry = QueuedEntry;
+type OutboxRunner = (input: unknown, entry: OutboxEntry) => Promise<unknown>;
+interface FlushResult {
+    sent: number;
+    failed: number;
+    remaining: number;
+    /**
+     * True when this call did no work because someone else was already flushing — another tab, or a
+     * re-entrant call.
+     *
+     * Distinct from `sent === 0`, which also happens when the flush *ran* and everything failed.
+     * Conflating them makes a failing server look like a busy tab, which sends whoever is debugging
+     * in exactly the wrong direction.
+     */
+    skipped: boolean;
+}
+declare class OutboxService {
+    private readonly options;
+    private readonly pending;
+    private readonly runners;
+    private readonly mineSignal;
+    private readonly foreignSignal;
+    private readonly flushingSignal;
+    /** This app's queued work, oldest first — what it can actually replay. */
+    readonly entries: Signal<readonly OutboxEntry[]>;
+    /**
+     * Work queued by another app on this page. Waiting, not stuck: it replays when its owner is
+     * mounted. Surfaced so an app can render "someone has unsent changes" honestly rather than
+     * reporting only what it can see of the queue.
+     */
+    readonly foreignEntries: Signal<readonly OutboxEntry[]>;
+    /**
+     * Unsent work across the whole page, not just this app's.
+     *
+     * "Are there unsent changes?" is a page-wide question, and each app answering only for itself is
+     * how the indicator was wrong before. Use {@link entries} when you need what *this* app owns.
+     */
+    readonly pendingCount: Signal<number>;
+    readonly hasPendingWork: Signal<boolean>;
+    readonly isFlushing: Signal<boolean>;
+    private outbox;
+    private loaded;
+    private get queue();
+    /**
+     * Registers how a mutation id replays. Called by `mutation()` at creation, which is why outbox
+     * mutations must be constructed during app start-up rather than lazily inside a click handler —
+     * otherwise a queued entry has nothing to replay into after a reload.
+     */
+    register(mutationId: string, runner: OutboxRunner): void;
+    /** Rehydrates from storage. Safe to call repeatedly. */
+    load(): Promise<void>;
+    enqueue(entry: {
+        mutationId: string;
+        input: unknown;
+        schemaVersion?: number;
+        /** What readers should show for the records this entry changes, until it is confirmed. */
+        optimistic?: OptimisticOverlay[];
+    }): Promise<OutboxEntry>;
+    /**
+     * Drains this app's queue in order.
+     *
+     * The rules — sequential, stop at the first failure, one drain per owner across every tab, give up
+     * loudly — live in `@braidlabs/data`'s `drainOutbox`, because this service used to carry a second
+     * copy of them and the two had already drifted apart on what to do with an entry nobody can
+     * replay. What stays here is the Angular half: signals, and re-reading the shared store into them.
+     *
+     * Only this app's entries are touched. Another app's queued work is left exactly where it is.
+     */
+    flush(): Promise<FlushResult>;
+    /**
+     * Removes one entry, and with it the overlay derived from it.
+     *
+     * What a confirmation does, and equally what a rollback does — at this level they are the same
+     * operation, which is the point of deriving the optimistic view rather than keeping an undo log.
+     */
+    remove(id: string): Promise<void>;
+    /**
+     * Discards this app's queued work. Sign-out, or an explicit "abandon my changes".
+     *
+     * Another app's entries survive: discarding work this app never queued and cannot replay would be
+     * deciding on someone else's behalf.
+     */
+    clear(): Promise<void>;
+    /**
+     * Re-reads the shared store into signals. The store is the truth; signals are a view of it.
+     *
+     * The optimistic overlay is rebuilt here too, from the same read. That is what makes the overlay
+     * derived rather than remembered: a reload, another app's write, and a rolled-back entry all reach
+     * the screen through this one path, because all three are just a different queue.
+     */
+    private refresh;
+    static ɵfac: i0.ɵɵFactoryDeclaration<OutboxService, never>;
+    static ɵprov: i0.ɵɵInjectableDeclaration<OutboxService>;
+}
+
+/**
+ * A read that normalizes into the shared store.
+ *
+ * Angular's own `resource()` / `httpResource()` cannot do this: there is no
+ * integration point that lets a third-party store observe what they fetched.
+ * So this is a parallel primitive rather than an extension — duplication we
+ * would happily delete if the framework grew the hook.
+ */
+type QueryStatus = 'idle' | 'loading' | 'success' | 'error';
+interface QueryConfig<T> {
+    /** Fetches the data. Anything promise-returning. */
+    readonly loader: () => Promise<T>;
+    /**
+     * Entity types present in the response. Every matching record is written to
+     * the store, so other views of the same entity update automatically.
+     */
+    readonly normalize?: EntityType<any> | ReadonlyArray<EntityType<any>>;
+    /** Tags this query depends on; invalidating any of them re-runs it. */
+    readonly tags?: () => readonly string[];
+    /** Run immediately on creation. Default true. */
+    readonly immediate?: boolean;
+}
+interface QueryRef<T> {
+    readonly value: Signal<T | undefined>;
+    readonly status: Signal<QueryStatus>;
+    readonly error: Signal<unknown>;
+    readonly isLoading: Signal<boolean>;
+    /** Re-runs the loader, bypassing any tag bookkeeping. */
+    reload(): Promise<void>;
+}
+/**
+ * Creates a query. Must be called in an injection context.
+ *
+ * ```ts
+ * readonly bulletins = query({
+ *   loader: () => firstValueFrom(this.http.get<Bulletin[]>('/api/bulletins')),
+ *   normalize: Bulletin,
+ *   tags: () => ['bulletins'],
+ * });
+ *
+ * // Read through the store, not through `bulletins.value()`:
+ * readonly rows = this.store.selectAll(Bulletin);
+ * ```
+ */
+declare function query<T>(config: QueryConfig<T>): QueryRef<T>;
+/**
+ * Walks a payload and writes every recognised entity into the store.
+ *
+ * Handles the shapes real APIs return: a bare record, an array, or an envelope
+ * such as `{ items: [...] }`. Anything unrecognised is left alone rather than
+ * guessed at — a wrong write into the shared graph is worse than no write.
+ */
+declare function normalizeInto(store: EntityStore, types: EntityType<any> | ReadonlyArray<EntityType<any>>, payload: unknown): void;
+
+/**
+ * A write, with the three things every application ends up reimplementing:
+ * optimistic application, rollback on failure, and durability.
+ *
+ * All three are one mechanism here: the **queue**. A write is queued before it
+ * is sent, every reader derives `confirmed ⊕ pending` from that queue, and
+ * settling it — confirmed or abandoned — is deleting the entry. There is no undo
+ * log, because there is nothing to undo: nothing was written to the confirmed
+ * graph in the first place.
+ *
+ * That is a change from the obvious design, and the reason is what the obvious
+ * design cannot do. An optimistic patch applied to the store with an undo log in
+ * memory is invisible to the other apps on the page and does not survive a
+ * reload — so a user who queues a change offline and refreshes sees the *old*
+ * value while their edit sits in storage waiting to send.
+ */
+type MutationStatus = 'idle' | 'pending' | 'success' | 'error';
+/**
+ * The server accepted the write and stored something else.
+ *
+ * Not a failure — servers normalize, resolve, and apply rules the client does
+ * not know about — which is exactly why it is so easy to ship a UI that swaps
+ * the value under whoever just typed it.
+ */
+interface MutationConflict {
+    /** The record as the screen showed it: confirmed, with this write's prediction applied. */
+    expected: unknown;
+    /** The record the server reported. */
+    actual: unknown;
+    /** The predicted fields the server disagreed about. */
+    paths: readonly string[];
+    /** Which record this is about. */
+    entity: {
+        typeName: string;
+        id: string;
+    };
+}
+/**
+ * What to do when the server disagrees.
+ *
+ * `'raise'` by default. The stored record becomes the server's value either way — you cannot make a
+ * server hold your value without another mutation — so the only question is whether the user is
+ * told, and the silent answer is a support ticket about someone's money.
+ */
+type ConflictPolicy = 'raise' | 'accept' | ((conflict: MutationConflict) => unknown);
+interface MutationConfig<TInput, TResult> {
+    /**
+     * Stable identifier. Required when `durability: 'outbox'`, because a queued
+     * entry outlives the closure and must find its operation again by name after
+     * a reload.
+     */
+    readonly id?: string;
+    readonly operation: (input: TInput) => Promise<TResult>;
+    /**
+     * Describes the change locally before the server has agreed.
+     *
+     * Still a callback taking a transaction, and still written exactly as it was —
+     * but the transaction now **records** rather than writes. `tx.patch(Bulletin,
+     * id, { status: 'published' })` was always a description; recording it is what
+     * lets the same description survive a reload, which a closure never could.
+     */
+    readonly optimistic?: (tx: StoreTransaction, input: TInput) => void;
+    /**
+     * Normalizes the server's response back into the store — the confirmed half.
+     *
+     * Receives the value chosen by `onConflict` when a resolver returned one, so a
+     * team that reconciles a disagreement writes the reconciled record rather than
+     * having to re-apply it afterwards.
+     */
+    readonly onSuccess?: (store: EntityStore, result: TResult, input: TInput) => void;
+    /** Tags to mark stale once the write lands. */
+    readonly invalidates?: (input: TInput, result?: TResult) => readonly string[];
+    /**
+     * `'outbox'` persists the mutation so it survives a reload and replays when
+     * connectivity returns. `'memory'` (default) fails fast.
+     *
+     * The overlay is derived from the queue either way. The difference is what
+     * rebuilds it: a persisted entry can be read back after a reload, and an
+     * in-memory one correctly dies with the page that made it.
+     */
+    readonly durability?: 'memory' | 'outbox';
+    /** Payload contract version, carried on queued entries. */
+    readonly schemaVersion?: number;
+    /** Defaults to `'raise'`. */
+    readonly onConflict?: ConflictPolicy;
+}
+interface MutationRef<TInput, TResult> {
+    mutate(input: TInput): Promise<TResult>;
+    readonly status: Signal<MutationStatus>;
+    readonly error: Signal<unknown>;
+    readonly isPending: Signal<boolean>;
+    /** True while this mutation's prediction is on screen and unconfirmed. */
+    readonly hasPendingWrite: Signal<boolean>;
+    /** The last disagreement, under the `'raise'` policy. Cleared by the next attempt. */
+    readonly conflict: Signal<MutationConflict | null>;
+    /** Dismisses a raised conflict, once the user has seen it. */
+    acknowledgeConflict(): void;
+}
+/**
+ * Creates a mutation. Must be called in an injection context.
+ *
+ * ```ts
+ * readonly publish = mutation({
+ *   id: 'bulletin.publish',
+ *   operation: (b: Bulletin) => firstValueFrom(this.http.post(`/api/bulletins/${b.id}/publish`, b)),
+ *   optimistic: (tx, b) => tx.patch(Bulletin, b.id, { status: 'published' }),
+ *   invalidates: (b) => [tag.entity(Bulletin, b.id), 'bulletins'],
+ *   durability: 'outbox',
+ *   schemaVersion: 41,
+ * });
+ * ```
+ */
+declare function mutation<TInput, TResult>(config: MutationConfig<TInput, TResult>): MutationRef<TInput, TResult>;
+
+/**
+ * Enables the data layer.
+ *
+ * ```ts
+ * provideSkewData({
+ *   owner: 'bulletin',
+ *   persistOutbox: true,
+ *   buildId: BUILD_ID,
+ *   onOutboxError: (message, detail) => telemetry.error(message, detail),
+ * });
+ * ```
+ */
+declare function provideSkewData(input?: DataOptionsInput): EnvironmentProviders;
+
+export { CacheRegistry, DATA_OPTIONS, EntityStore, OUTBOX_COLLECTION, OutboxService, PendingWrites, applyOverlays, entity, fromOutboxOverlay, mutation, normalizeInto, overlayKey, provideSkewData, query, recordOverlays, resolveDataOptions, tag, tagsMatch, toOutboxOverlay };
+export type { ConflictPolicy, DataOptions, DataOptionsInput, EntityDefinition, EntityOverlay, EntityType, FlushResult, MutationConfig, MutationConflict, MutationRef, MutationStatus, OutboxEntry, OutboxRunner, QueryConfig, QueryRef, QueryStatus, RecordedWrites, StoreTransaction };