stream-chat 9.50.3 → 10.0.0-rc.2

package/dist/types/pagination/paginators/ChannelPaginator.d.ts

@@ -0,0 +1,212 @@
+import type { ItemCoordinates, PaginationQueryParams, PaginationQueryReturnValue, PaginatorOptions, PaginatorState, PostQueryReconcileParams, SetPaginatorItemsParams } from './BasePaginator';
+import { BasePaginator } from './BasePaginator';
+import type { FilterBuilderOptions } from '../FilterBuilder';
+import { FilterBuilder } from '../FilterBuilder';
+import type { StreamChat } from '../../client';
+import type { Channel } from '../../channel';
+import type { ChannelFilters, ChannelOptions, ChannelSort, ChannelStateOptions, ParsedPredefinedFilterResponse, QueryChannelsRequest } from '../../types';
+/**
+ * The `queryChannels` request this paginator will send, plus the client-only `stateOptions`.
+ *
+ * Deliberately the request's own shape (`filter_conditions`, `sort`, `limit`, `predefined_filter`, …)
+ * rather than a `{ filters, sort, options }` wrapper: the same object goes on the wire, keys the
+ * offline-db cache and is compared for query-shape changes, so any field mapping in between would be a
+ * place for those three to drift apart. `MessageQueryShape` is likewise the request params themselves.
+ */
+export type ChannelQueryShape = QueryChannelsRequest & {
+    /** Not part of the request — controls how the response is applied to client state. */
+    stateOptions?: ChannelStateOptions;
+};
+export type ChannelPaginatorState = PaginatorState<Channel>;
+export type ChannelPaginatorRequestOptions = Partial<Omit<ChannelOptions, 'offset' | 'limit'>>;
+export type ChannelSortComparatorFactoryParams = {
+    /** Sort the comparator is being built for — the effective sort, so a backend-resolved sort template. */
+    sort: ChannelSort;
+    /**
+     * The comparator `ChannelPaginator` would use for this sort. Delegate to it for the fields you do not
+     * want to handle yourself instead of reimplementing channel field resolution and the cid tiebreaker.
+     */
+    defaultComparator: (a: Channel, b: Channel) => number;
+};
+/**
+ * Produces the comparator that orders this paginator's channels. Consulted on **every** comparator
+ * rebuild (construction, `sort` change, backend-resolved predefined sort), so unlike assigning
+ * `sortComparator` directly, a factory is not overwritten by later sort changes.
+ */
+export type ChannelSortComparatorFactory = (params: ChannelSortComparatorFactoryParams) => (a: Channel, b: Channel) => number;
+export type ChannelPaginatorOptions = {
+    client: StreamChat;
+    channelStateOptions?: ChannelStateOptions;
+    filterBuilderOptions?: FilterBuilderOptions<ChannelFilters>;
+    filters?: ChannelFilters;
+    id?: string;
+    paginatorOptions?: PaginatorOptions<Channel, ChannelQueryShape>;
+    requestOptions?: ChannelPaginatorRequestOptions;
+    sort?: ChannelSort;
+    sortComparatorFactory?: ChannelSortComparatorFactory;
+};
+/**
+ * A paginated channel list. Filters are described along three independent axes — the names follow them:
+ *
+ * - origin: `staticFilters` are supplied at construction and fixed; `filterBuilder` generates the
+ *   dynamic ones from its reactive context on every build. Every build merges dynamic over static.
+ * - authority: `staticFilters` are what this client asked for; `predefinedFilter` is what the backend
+ *   reports it actually applied for a `predefined_filter` query. `effectiveFilters` is the winner of the
+ *   two (and `effectiveSort` likewise for ordering).
+ * - purpose: `buildQueryFilters()` produces the filters sent to the server (and the offline-db query
+ *   key), built from the local filters only; `buildMatchFilters()` produces the filters items are
+ *   matched against locally, built from `effectiveFilters`. They are not interchangeable: sending the
+ *   resolved filter back changes the query shape mid-pagination, and matching against the local filter
+ *   admits channels the queried list excludes.
+ *
+ * Ordering follows the same authority rule: `sortComparator` is derived from `effectiveSort` and is
+ * rebuilt whenever that changes, so it must not be assigned to. Customize it through
+ * `sortComparatorFactory` (constructor option or setter, consulted on every rebuild) or by overriding
+ * `buildSortComparator` in a subclass.
+ */
+export declare class ChannelPaginator extends BasePaginator<Channel, ChannelQueryShape> {
+    private readonly _id;
+    private client;
+    protected _staticFilters: ChannelFilters | undefined;
+    protected _sort: ChannelSort | undefined;
+    protected _options: ChannelPaginatorRequestOptions | undefined;
+    protected _channelStateOptions: ChannelStateOptions | undefined;
+    protected _nextQueryShape: ChannelQueryShape | undefined;
+    /** Backend-reported metadata of the last `predefined_filter` query (see `predefinedFilter`). */
+    protected _predefinedFilter: ParsedPredefinedFilterResponse | undefined;
+    /**
+     * Predefined-filter metadata from the response of the query currently in flight. Held until
+     * `postQueryReconcile` decides whether it should be committed (first page only).
+     */
+    private _pendingPredefinedFilter;
+    protected _sortComparatorFactory: ChannelSortComparatorFactory | undefined;
+    sortComparator: (a: Channel, b: Channel) => number;
+    filterBuilder: FilterBuilder<ChannelFilters>;
+    constructor({ channelStateOptions, client, id, filterBuilderOptions, filters, paginatorOptions, requestOptions, sort, sortComparatorFactory, }: ChannelPaginatorOptions);
+    /**
+     * Builds the comparator for the given sort — the single construction point, so every rebuild (the
+     * `sort` setter, a backend-resolved predefined sort) keeps the channel-specific path resolver and the
+     * cid tiebreaker; omitting either makes ordering fall back to raw `channel.data` lookups and become
+     * non-deterministic for equal sort values.
+     *
+     * `sortComparator` is derived state and is therefore reassigned on every rebuild — assigning to it
+     * directly does not survive a sort change or a predefined-filter response. To customize ordering,
+     * supply `sortComparatorFactory` (it is consulted on every rebuild and may delegate to
+     * `defaultComparator`), or override this method in a subclass.
+     */
+    protected buildSortComparator(sort: ChannelSort): (a: Channel, b: Channel) => number;
+    get id(): string;
+    get isOfflineSupportEnabled(): boolean;
+    get staticFilters(): ChannelFilters | undefined;
+    get sort(): ChannelSort;
+    /**
+     * What the backend reported it actually filtered and sorted by for the last first-page query —
+     * `QueryChannelsResponse.predefined_filter` (`name`, `filter`, and `sort` when the stored filter
+     * carries its own sort template). Set only for `predefined_filter` queries: the raw `filter_conditions`
+     * of a normal query are not echoed back.
+     */
+    get predefinedFilter(): ParsedPredefinedFilterResponse | undefined;
+    /**
+     * Filters this paginator matches items against client-side. A predefined filter resolved by the backend
+     * wins over the locally configured one: for such a query the local `filters` are not what the server
+     * applied, so matching against them would admit items the queried list excludes.
+     */
+    get effectiveFilters(): ChannelFilters | undefined;
+    /**
+     * Sort this paginator orders items by. Mirrors `effectiveFilters`: a sort template carried by a
+     * backend-resolved predefined filter takes precedence over the requested sort, matching backend
+     * precedence rules.
+     */
+    get effectiveSort(): ChannelSort;
+    get options(): ChannelOptions | undefined;
+    get channelStateOptions(): ChannelStateOptions | undefined;
+    set staticFilters(filters: ChannelFilters | undefined);
+    set sort(sort: ChannelSort | undefined);
+    set options(options: ChannelPaginatorRequestOptions | undefined);
+    set channelStateOptions(options: ChannelStateOptions | undefined);
+    get sortComparatorFactory(): ChannelSortComparatorFactory | undefined;
+    /**
+     * Take over channel ordering at any point in the paginator's life. The comparator is rebuilt
+     * immediately and the factory is consulted again on every later rebuild, so — unlike assigning
+     * `sortComparator` — a sort change or a backend-resolved predefined sort will not discard it. Set to
+     * `undefined` to go back to the built-in ordering.
+     */
+    set sortComparatorFactory(factory: ChannelSortComparatorFactory | undefined);
+    getItemId(item: Channel): string;
+    /**
+     * Filters sent to the server with the next query (and used as the offline-db query key). Deliberately
+     * built from the locally configured filters only — feeding the backend-resolved filter back in would
+     * change the query shape after the first response and make the following page look like a new first
+     * page to `hasPaginationQueryShapeChanged`.
+     */
+    buildQueryFilters: () => ChannelFilters;
+    /**
+     * Filters items are matched against locally — the `BasePaginator.buildMatchFilters` hook consumed by
+     * `matchesFilter`. Built from `effectiveFilters`, so a `predefined_filter` list matches what the
+     * backend applied rather than the local filters, which are not what produced the list.
+     */
+    buildMatchFilters: () => ChannelFilters;
+    matchesFilter(channel: Channel): boolean;
+    /**
+     * Commits the `predefined_filter` metadata of the response, or clears it when the response carried
+     * none (a plain `filter_conditions` query), so a switch away from a predefined filter cannot leave
+     * stale matching/ordering semantics behind.
+     */
+    protected applyPredefinedFilterResponse(predefinedFilter: ParsedPredefinedFilterResponse | undefined): void;
+    /**
+     * The response metadata describes the query as a whole, so it is (re)committed only when a first page
+     * lands — matching the legacy `ChannelManager`, which kept it untouched while paginating. A failed
+     * query (`results === null`) must not drop the metadata of the already loaded list either.
+     *
+     * Committing before `super` matters: the base implementation filters and ingests the page using
+     * `matchesFilter` and the comparators this metadata feeds.
+     */
+    postQueryReconcile(params: PostQueryReconcileParams<Channel, ChannelQueryShape>): import("./BasePaginator").ExecuteQueryReturnValue<Channel>;
+    protected getNextQueryShape(): ChannelQueryShape;
+    /** The query that produced the currently loaded list, i.e. the cache key its cids belong under. */
+    protected get loadedQueryRequest(): QueryChannelsRequest;
+    /**
+     * Writes a cid order into the offline cache under the query that produced it.
+     *
+     * `filters` and `sort` are passed separately even though `options` already contains them: the concrete
+     * (RN) DB implementation derives the cache row key from those two top-level arguments in
+     * `convertFilterSortToQuery`, while `options` carries the full request — the only place
+     * `predefined_filter` / `filter_values` / `sort_values` appear, without which two predefined-filter
+     * lists cannot be told apart. The duplication goes away once `convertFilterSortToQuery` derives the
+     * key from `options` (a change in that implementation plus a schema-version bump to flush stale rows).
+     */
+    protected cacheCidsForQuery({ cids, request, }: {
+        cids: string[];
+        request: QueryChannelsRequest;
+    }): void;
+    /**
+     * Persists the current cid order under the query that produced it. Called after every mutation of the
+     * loaded list — including live WS-driven inserts/removals, which reorder the list without any query
+     * running; skipping those would leave the cached order stale until the next full re-query.
+     */
+    protected persistLoadedCids(): void;
+    preloadFirstPageFromOfflineDb: ({ queryShape, }: PaginationQueryParams<ChannelQueryShape>) => Promise<Channel[] | undefined>;
+    populateOfflineDbAfterQuery: ({ items, queryShape, }: {
+        items?: Channel[];
+        queryShape?: ChannelQueryShape;
+    }) => undefined;
+    /**
+     * Postpones a first-page query while the offline sync is still in progress: the cached page is
+     * surfaced right away and the network query is handed to the sync manager, which re-runs it once
+     * reconciliation finished — querying (and persisting cids) against unsynced local state would race
+     * with the replay of pending local mutations. Mirrors `ChannelManager.queryChannels`, which deferred
+     * on every unsynced call and read the cache only when it had nothing loaded yet.
+     *
+     * Only first-page queries defer; paginating an already loaded list is unaffected (as was the legacy
+     * `loadNext`).
+     */
+    executeQuery(params?: PaginationQueryParams<ChannelQueryShape>): Promise<void | import("./BasePaginator").ExecuteQueryReturnValue<Channel>>;
+    query: () => Promise<PaginationQueryReturnValue<Channel>>;
+    filterQueryResults: (items: Channel[]) => Channel[];
+    setItems(params: SetPaginatorItemsParams<Channel>): void;
+    ingestItem(channel: Channel): boolean;
+    removeItem(params: {
+        id?: string;
+        item?: Channel;
+    }): ItemCoordinates;
+}

package/dist/types/pagination/paginators/MessageIntervalPaginator.d.ts

@@ -0,0 +1,282 @@
+import type { PaginationDirection, PaginationQueryParams, PaginatorState } from './BasePaginator';
+import { BasePaginator, type PaginationQueryReturnValue, type PaginatorOptions } from './BasePaginator';
+import type { LocalMessage, MessagePaginationOptions, MessageResponse, PinnedMessagePaginationOptions, ReactionResponse, SortParamRequest, UserResponse } from '../../types';
+import type { Channel } from '../../channel';
+import { StateStore } from '../../store';
+import type { ItemIndexApi } from '../ItemIndex';
+import type { EntityStoreChangeBatch } from '../../entityStore/EntityStore';
+export type MessageFocusReason = 'jump-to-message' | 'jump-to-first-unread' | 'jump-to-latest';
+export type MessageFocusSignal = {
+    messageId: string;
+    reason: MessageFocusReason;
+    token: number;
+    createdAt: number;
+    ttlMs: number;
+};
+export type MessageFocusSignalState = {
+    signal: MessageFocusSignal | null;
+};
+export type JumpToMessageOptions = {
+    pageSize?: number;
+    /**
+     * Optional reason attached to emitted focus signal.
+     * Defaults to `jump-to-message`.
+     */
+    focusReason?: MessageFocusReason;
+    /**
+     * TTL for the emitted focus signal in milliseconds.
+     * Defaults to `3000`.
+     */
+    focusSignalTtlMs?: number;
+    /**
+     * If true, suppresses focus signal emission after a successful jump.
+     */
+    suppressFocusSignal?: boolean;
+};
+export type MessagePaginatorSort = SortParamRequest[];
+export type MessagePaginatorFilter = {
+    cid: string;
+    parent_id?: string;
+};
+export type MessagePaginatorState = PaginatorState<LocalMessage>;
+export type MessageQueryShape = MessagePaginationOptions | PinnedMessagePaginationOptions;
+export declare const getMessageCreatedAtTimestamp: (message: LocalMessage) => number | null;
+export type MessagePaginatorOptions = {
+    channel: Channel;
+    id?: string;
+    itemIndex?: ItemIndexApi<LocalMessage>;
+    parentMessageId?: string;
+    /**
+     * Sort passed to backend message/replies query.
+     * Does not affect in-memory item ordering.
+     */
+    requestSort?: MessagePaginatorSort;
+    /**
+     * @deprecated Use `requestSort` instead.
+     */
+    sort?: MessagePaginatorSort;
+    /**
+     * In-memory ordering for items exposed by paginator state.
+     */
+    itemOrder?: MessagePaginatorSort;
+    paginatorOptions?: PaginatorOptions<LocalMessage, MessageQueryShape>;
+};
+/**
+ * MessageIntervalPaginator allows configuring backend request sort, while keeping internal item ordering stable.
+ * Filtering of ingested items is still limited to local predicates (`filterQueryResults`).
+ */
+export declare class MessageIntervalPaginator extends BasePaginator<LocalMessage, MessageQueryShape> {
+    state: StateStore<MessagePaginatorState>;
+    private readonly _id;
+    protected channel: Channel;
+    protected parentMessageId?: string;
+    readonly messageFocusSignal: StateStore<MessageFocusSignalState>;
+    private clearMessageFocusSignalTimeoutId;
+    private messageFocusSignalToken;
+    protected _requestSort: MessagePaginatorSort;
+    protected _itemOrder: MessagePaginatorSort;
+    protected _nextQueryShape: MessageQueryShape | undefined;
+    sortComparator: (a: LocalMessage, b: LocalMessage) => number;
+    /**
+     * Single source of truth for whether a message should be included in paginator intervals/state.
+     * Keep this consistent with `filterQueryResults` AND cursor flag derivation.
+     */
+    shouldIncludeMessageInInterval(message: LocalMessage): boolean;
+    /**
+     * Entity-store adapter (this paginator is an `EntityStoreSubscriber`): the `EntityStore` calls this
+     * on each holder with the subset of its watched ids that changed. Unwraps the batch and delegates to
+     * the base's store-agnostic {@link BasePaginator.reconcileChangedIds}. Lives here, not on the generic
+     * `BasePaginator`, so the base stays free of `EntityStore` types — only message paginators are
+     * store-backed.
+     */
+    onEntitiesChanged({ changedIds }: EntityStoreChangeBatch): void;
+    /**
+     * Entity-store subscriber flush (the optional `EntityStoreSubscriber.flushState`): the `EntityStore`
+     * calls this after an optimistic (local-user) write so the change renders without throttle delay.
+     * Delegates to the base's generic {@link BasePaginator.flushPendingPublishes}.
+     */
+    flushState(): void;
+    protected get intervalItemIdsAreHeadFirst(): boolean;
+    protected get intervalSortDirection(): 'asc' | 'desc';
+    constructor({ channel, id, itemIndex, parentMessageId, requestSort, sort, itemOrder, paginatorOptions, }: MessagePaginatorOptions);
+    get id(): string;
+    get sort(): MessagePaginatorSort;
+    get requestSort(): MessagePaginatorSort;
+    get itemOrder(): MessagePaginatorSort;
+    /**
+     * Even though we do not send filters object to the server, we need to have filters for client-side item ingestion logic.
+     */
+    buildMatchFilters: () => MessagePaginatorFilter;
+    protected getNextQueryShape({ direction, }: Omit<PaginationQueryParams<MessageQueryShape>, 'isFirstPageQuery'>): MessageQueryShape;
+    getCursorFromQueryResults: ({ direction, items, }: {
+        direction?: PaginationDirection;
+        items: LocalMessage[];
+    }) => {
+        tailward: string | undefined;
+        headward: string | undefined;
+    };
+    query: ({ direction, }: PaginationQueryParams<MessageQueryShape>) => Promise<PaginationQueryReturnValue<LocalMessage>>;
+    /**
+     * Seed the paginator with the page a channel-open query just fetched (`Channel.query` for
+     * `watch`/`create`, and `client.hydrateActiveChannels`).
+     *
+     * These paths hydrate the channel read state in the SAME synchronous tick they add messages
+     * (`Channel._initializeState`), and the read patch drives `MessageReceiptsTracker`, which resolves
+     * read/delivered cursors against this paginator (`findItemByTimestamp`) whenever the server omits
+     * the `last_read_message_id` / `last_delivered_message_id`. `postQueryReconcile` is fully
+     * synchronous (filtering is a local predicate), so seeding here guarantees the paginator is
+     * populated before the reconcile runs. First-page reconciliation also takes the unread snapshot.
+     *
+     * The fetched page is NOT always the latest window: a channel can be opened AROUND a message
+     * (`messages: { id_around }` / `{ created_at_around }`), so the original pagination options are
+     * threaded through as the query shape. For an around/jump open this lets `postQueryReconcile`
+     * apply jump semantics (no forced head/tail; cursor flags derived from the around position)
+     * instead of wrongly flagging the window as the head (newest) page.
+     */
+    seedFirstPageSync(messages: LocalMessage[], requestedPageSize: number, messagePaginationOptions?: MessagePaginationOptions): void;
+    isJumpQueryShape(queryShape: MessageQueryShape): boolean;
+    jumpToMessage: (messageId: string, { focusReason, focusSignalTtlMs, pageSize, suppressFocusSignal, }?: JumpToMessageOptions) => Promise<boolean>;
+    jumpToTheLatestMessage: (options?: JumpToMessageOptions) => Promise<boolean>;
+    /**
+     * Fold an already fetched newest (head) page into the currently loaded items without issuing a
+     * query. The caller supplies a page it obtained on its own and this reconciles it against what is
+     * loaded, instead of rerunning the first page query, so the loaded set is updated in place rather
+     * than blanked and reloaded. Two cases, decided by whether the incoming page overlaps the loaded
+     * head:
+     *
+     * 1. OVERLAP - the incoming page shares at least one id with the loaded head (fewer than a full
+     *    page is new). Merge in place: existing items are reconciled by id (edits, soft deletes), new
+     *    items are appended and every already loaded item (including older pages already paged in) is
+     *    kept. `hasMoreTail`/`cursor.tailward` are left as-is so the page can be any size, so deriving
+     *    "has older items" from its length would wrongly clear it while older items remain.
+     *
+     * 2. DISJOINT - the incoming page shares no id with the loaded head (at least a full page is new).
+     *    Merging would weld the two across the gap (the interval merge treats two head intervals as
+     *    overlapping when one reaches further headward), hiding the items in between with no way to
+     *    reach them. Instead the loaded set is discarded and rebuilt from the incoming page as a fresh
+     *    contiguous head (`hasMoreTail: true`, cursor reanchored to the page's oldest item) so the
+     *    gap and older history load again when paginating older.
+     *
+     * Both paths emit exactly once and never blank the loaded set. Noop unless the page is non empty
+     * and the newest slice is both loaded AND the interval currently in view (the head interval is
+     * anchored at the head and active); when the caller has jumped to a separate older window the
+     * merge is skipped so their position is preserved, and the incoming page is picked up on a later
+     * load.
+     */
+    mergeNewestPage: (page: LocalMessage[]) => void;
+    protected resolveUnreadBoundaryIdsByTimestamp: ({ lastReadAt, messages, }: {
+        lastReadAt: Date;
+        messages: LocalMessage[];
+    }) => {
+        firstUnreadMessageId: string | null;
+        lastReadMessageId: string | null;
+    };
+    emitMessageFocusSignal: ({ messageId, reason, ttlMs, }: {
+        messageId: string;
+        reason: MessageFocusReason;
+        ttlMs?: number;
+    }) => MessageFocusSignal;
+    /**
+     * Starts the auto-dismissal countdown for the currently active focus signal. Call this once the
+     * focused message has been viewed (rendered and visible), so the highlight's lifetime is measured
+     * from when the user could actually see it rather than from when the jump resolved. No-op if the
+     * signal has already been cleared or superseded (guarded by `token`).
+     */
+    scheduleMessageFocusSignalClear: ({ token, ttlMs, }?: {
+        token?: number;
+        ttlMs?: number;
+    }) => void;
+    clearMessageFocusSignal: ({ token }?: {
+        token?: number;
+    }) => void;
+    clearStateAndCache(): void;
+    /**
+     * Partial truncation for `channel.truncated` carrying a `truncated_at`: drop every loaded
+     * message strictly older than the cutoff (keeping newer ones) across all loaded windows,
+     * mirroring the legacy per-message-set pruning. For a full truncation (no `truncated_at`) use
+     * {@link MessageIntervalPaginator.clearStateAndCache} instead.
+     *
+     * Batched and edge-classified: because messages are chronological, each interval is classified by
+     * its `tail` (oldest) and `head` (newest) edges, so only the single interval that *straddles* the
+     * cutoff is scanned member-by-member — the rest are kept or dropped wholesale. The straddling
+     * interval becomes the new global tail (nothing older than the cutoff exists anymore), so its
+     * `isTail`/`hasMoreTail` are set; intervals entirely newer keep their flags (unloaded older
+     * messages may still sit between them and the cutoff). The active window is re-emitted once.
+     */
+    truncate: ({ truncatedAt }: {
+        truncatedAt: Date;
+    }) => void;
+    applyMessageDeletionForUser: ({ userId, hardDelete, deletedAt, }: {
+        userId: string;
+        hardDelete?: boolean;
+        deletedAt: Date;
+    }) => void;
+    /**
+     * Ensures quoted-message snapshots across loaded paginator cache are in sync
+     * with the provided message.
+     *
+     * Scans cached messages and updates any item where `quoted_message_id`
+     * matches `message.id`.
+     */
+    reflectQuotedMessageUpdate: (message: LocalMessage) => void;
+    /**
+     * Reflect an updated `user` object onto every cached message authored by that user, mirroring
+     * the legacy `ChannelState.updateUserMessages` for the main message list (does not touch
+     * `quoted_message.user` — that is not part of the legacy behavior).
+     *
+     * Batched: a user rename can affect many messages, so this patches the shared item index and
+     * re-emits the active window a single time (if it held an affected message) rather than one
+     * `ingestItem` re-emit per message.
+     */
+    reflectUserUpdate: (user: UserResponse) => void;
+    /**
+     * Apply a reaction WS event (`reaction.new` / `reaction.updated` / `reaction.deleted`) to the
+     * cached message. The event's `message` already carries the server-updated
+     * `reaction_groups` / `latest_reactions`; only `own_reactions` needs local preservation so a
+     * cross-user reaction does not wipe the current user's reactions. This re-homes what
+     * `ChannelState.addReaction` / `removeReaction` used to do off the now-removed
+     * `channel.state.messages` / `channel.state.threads` caches (the same logic backs the thread
+     * paginator via `Thread.messagePaginator`).
+     *
+     * `own_reactions` is seeded from the currently cached item (so another user's reaction keeps ours),
+     * falling back to the event's own_reactions when the message is not loaded — matching the legacy
+     * behavior where `_updateMessage` only mutated a message that existed locally.
+     *
+     * @param params - The reaction event payload.
+     * @param params.message - The reaction event's message, carrying the
+     *   server-computed `reaction_groups` / `latest_reactions`. Ingested as-is except for `own_reactions`.
+     * @param params.reaction - The reaction from the event. Only added to/removed from
+     *   `own_reactions` when its `user_id` is the current user; otherwise the current user's
+     *   `own_reactions` are left untouched.
+     * @param [params.removed=false] - `true` for `reaction.deleted` (remove the reaction from
+     *   `own_reactions`); `false` for `reaction.new` / `reaction.updated` (add it).
+     * @param [params.enforceUnique=false] - When adding, first clear the current user's existing
+     *   `own_reactions` so only the incoming one remains (used by `reaction.updated`, where a user's
+     *   reaction replaces their previous one).
+     *
+     * TODO(reactive-store): reflect reactions ONCE at the store level, not per-paginator. Both the
+     * channel handler (channel.ts) and the thread handler (thread.ts) call this on every reaction.*
+     * event, so a message held in more than one collection (a show_in_channel reply, or the thread
+     * parent) is reflected TWICE: two writes to the same canonical slot, each fanning out to the
+     * other holder (double re-projection) and minting a fresh ref that defeats the reconcile
+     * ref-equality bail. Idempotent (counts come wholesale from the event) so the result is correct,
+     * just wasteful. The store already fans out to every holder, so reflect once (by id, if held) and
+     * retire the per-collection reflect calls + parent path + enforce_unique branch.
+     */
+    reflectReaction: ({ enforceUnique, message, reaction, removed, }: {
+        message: MessageResponse | LocalMessage;
+        reaction: ReactionResponse;
+        enforceUnique?: boolean;
+        removed?: boolean;
+    }) => void;
+    /**
+     * Map a timestamp to a loaded message — the first message in the latest (head) window whose
+     * `created_at` is >= `timestampMs` (mirrors the legacy `ChannelState.findMessageByTimestamp`
+     * lower-bound search), or the newest loaded message when the timestamp is beyond it. Used by the
+     * receipts tracker to resolve read/delivered cursors. Searches the newest loaded window — where
+     * read cursors live — which is already sorted, so this is O(log n) with no re-sort.
+     */
+    findItemByTimestamp: (timestampMs: number, exactTsMatch?: boolean) => LocalMessage | null;
+    filterQueryResults: (items: LocalMessage[]) => LocalMessage[];
+    private getCanonicalQueryItems;
+}