@ethora/chat-component 26.7.5 → 26.7.7

package/dist/helpers/mentions.d.ts

@@ -0,0 +1,63 @@
+import { IMentionSpan, RoomMember } from '../types/types';
+export interface MentionCandidate {
+    jid: string;
+    name: string;
+}
+export declare const memberJid: (member: RoomMember) => string;
+export declare const memberFullName: (member: RoomMember) => string;
+/**
+ * Filters + ranks a room's members against a typed `@query` for the mention
+ * autocomplete dropdown. Prefix matches outrank mid-string substring
+ * matches; ties break alphabetically. The current user is always excluded
+ * (no self-mention suggestion).
+ */
+export declare const rankMentionCandidates: (query: string, members: RoomMember[], selfId?: string) => MentionCandidate[];
+/**
+ * Detects an in-progress "@query" the caret is currently inside, so the
+ * autocomplete dropdown knows whether to be open and what to filter by.
+ * Only triggers when the `@` starts a "word" (start of input, or preceded
+ * by whitespace) so it doesn't fire inside an email-looking string or an
+ * existing word.
+ */
+export declare const findActiveMentionQuery: (text: string, caret: number) => {
+    start: number;
+    query: string;
+} | null;
+/**
+ * Re-anchors mention spans after a text edit. `editStart`/`editEnd` are the
+ * [start, end) range of the OLD text that was replaced, `insertedLength` is
+ * how long the replacement text is. Spans entirely before the edit are left
+ * alone; spans entirely after are shifted by the net length delta; a span
+ * that overlaps the edited range is dropped (its underlying text is no
+ * longer intact, so it's no longer a valid mention).
+ */
+export declare const shiftMentionSpans: (spans: IMentionSpan[], editStart: number, editEnd: number, insertedLength: number) => IMentionSpan[];
+/**
+ * Drops any span whose text no longer reads "@Name" in the current body
+ * (e.g. a multi-character selection delete clipped part of it). Safety net
+ * on top of shiftMentionSpans for edits that aren't tracked precisely.
+ */
+export declare const validateMentionSpans: (text: string, spans: IMentionSpan[]) => IMentionSpan[];
+/** Finds a mention span whose token ends exactly at `caret` (i.e. the caret
+ * sits right after a complete "@Name" token) - used to make Backspace
+ * delete the whole token atomically instead of one character. */
+export declare const findMentionEndingAt: (spans: IMentionSpan[], caret: number) => IMentionSpan | undefined;
+/**
+ * Diffs two versions of the composer text (before/after a single onChange)
+ * down to the edited range, via longest common prefix/suffix. Good enough
+ * for the single-edit-at-a-time case a controlled <input>/<textarea>
+ * onChange always is (typing, pasting, cutting, IME commit): everything
+ * outside the diffed range is provably unchanged, which is what
+ * shiftMentionSpans needs to re-anchor mention offsets correctly.
+ */
+export declare const computeEditRange: (oldText: string, newText: string) => {
+    start: number;
+    end: number;
+    insertedLength: number;
+};
+/**
+ * Splices mention spans into `text` as raw `<mention>` tags for the
+ * markdown/rehype-raw pipeline to pick up (see parseMessageBody.tsx). Spans
+ * are applied back-to-front so earlier offsets stay valid while splicing.
+ */
+export declare const spliceMentionMarkup: (text: string, spans: IMentionSpan[] | undefined) => string;

package/dist/helpers/parseMessageBody.d.ts

@@ -1,4 +1,14 @@
-export declare const parseMessageBody: ({ text }: {
+import { IMentionSpan } from '../types/types';
+export interface MentionClickHandler {
+    (mention: {
+        jid: string;
+        name: string;
+    }): void;
+}
+interface ParseMessageBodyArgs {
     text: string;
-}) => import("react/jsx-runtime").JSX.Element;
+    mentions?: IMentionSpan[];
+    onMentionClick?: MentionClickHandler;
+}
+export declare const parseMessageBody: ({ text, mentions, onMentionClick, }: ParseMessageBodyArgs) => import("react/jsx-runtime").JSX.Element;
 export default parseMessageBody;

package/dist/helpers/pdf/loadPdfjs.d.ts

@@ -0,0 +1,64 @@
+/**
+ * Lazy, failure-tolerant access to pdf.js.
+ *
+ * Two things drive the shape of this module:
+ *
+ * 1. pdf.js is ~1.5 MB. It must never land in the chunk that a host pays for
+ *    on first paint, so it is only ever reached through `import()` from
+ *    here, and this module is itself only imported dynamically.
+ *
+ * 2. Wiring `GlobalWorkerOptions.workerSrc` from inside a library is a
+ *    portability trap: the URL has to survive our Vite lib build AND the
+ *    host's bundler (Vite, webpack, Next, CRA), and every published recipe
+ *    for it is bundler-specific. So by default we do not use a worker file
+ *    at all - importing the worker module and parking it on
+ *    `globalThis.pdfjsWorker` makes pdf.js run its message handler on the
+ *    main thread (see PDFWorker's `#mainThreadWorkerMessageHandler`). For a
+ *    one-page thumbnail that is a few milliseconds of main-thread work, and
+ *    it is bundler-agnostic. Hosts that render large PDFs can hand us a real
+ *    `workerSrc` through `config.pdfPreview.workerSrc` and get the worker
+ *    path back.
+ *
+ * Any failure (module missing, CSP blocking eval, unsupported browser)
+ * resolves to `null`; callers fall back to the static document card.
+ */
+export interface PdfRenderTask {
+    promise: Promise<void>;
+    cancel: () => void;
+}
+export interface PdfViewport {
+    width: number;
+    height: number;
+}
+export interface PdfPageProxy {
+    getViewport: (params: {
+        scale: number;
+    }) => PdfViewport;
+    render: (params: {
+        canvasContext: CanvasRenderingContext2D;
+        viewport: PdfViewport;
+    }) => PdfRenderTask;
+    cleanup: () => void;
+}
+export interface PdfDocumentProxy {
+    numPages: number;
+    getPage: (pageNumber: number) => Promise<PdfPageProxy>;
+    destroy: () => Promise<void>;
+}
+export interface PdfDocumentLoadingTask {
+    promise: Promise<PdfDocumentProxy>;
+    destroy: () => Promise<void>;
+}
+export interface PdfjsLib {
+    getDocument: (params: {
+        url: string;
+        withCredentials?: boolean;
+        isEvalSupported?: boolean;
+    }) => PdfDocumentLoadingTask;
+    GlobalWorkerOptions: {
+        workerSrc: string;
+    };
+}
+/** Test seam - the module-level cache would otherwise leak between cases. */
+export declare const resetPdfjsCache: () => void;
+export declare const loadPdfjs: (workerSrc?: string) => Promise<PdfjsLib | null>;

package/dist/helpers/remarkLineBreaks.d.ts

@@ -0,0 +1,42 @@
+/**
+ * A tiny local stand-in for `remark-breaks`.
+ *
+ * In CommonMark a single "\n" inside a paragraph is a "soft break": it is
+ * kept as a literal newline character inside the surrounding mdast `text`
+ * node, and every renderer (ours included) turns that into a plain space.
+ * That is what made a message typed with real line breaks collapse into
+ * one line once it went through react-markdown.
+ *
+ * `remark-breaks` fixes this by rewriting each soft break into a real
+ * mdast `break` node (which renders as `<br />`). We do the same thing by
+ * hand instead of adding that package (or `unist-util-visit`) as a new
+ * dependency: this is a published SDK, and the tree walk below is a dozen
+ * lines.
+ *
+ * Only `text` nodes carry this problem. Fenced/indented code, inline code
+ * spans and raw HTML passthrough all keep their literal newlines as part
+ * of their own syntax (a `code`/`inlineCode` node's content lives in
+ * `value`, not in child `text` nodes, and an `html` node is a leaf too),
+ * so the walk below never touches them - it only ever rewrites `text`
+ * children, and only descends into nodes that actually have children.
+ *
+ * Existing hard breaks (two trailing spaces, or a trailing backslash,
+ * before a newline) are already parsed into their own `break` node by the
+ * time a remark plugin sees the tree - the newline itself is consumed by
+ * that syntax and never ends up inside a `text` node's value. So there is
+ * nothing left for this plugin to find there, and it cannot double them.
+ */
+export interface MarkdownAstNode {
+    type: string;
+    value?: string;
+    children?: MarkdownAstNode[];
+    [key: string]: unknown;
+}
+/**
+ * Remark plugin: turns every soft line break in the document into a real
+ * `break` node. Usage mirrors any other remark plugin:
+ *
+ *   remarkPlugins={[remarkGfm, remarkLineBreaks]}
+ */
+export declare const remarkLineBreaks: () => (tree: MarkdownAstNode) => void;
+export default remarkLineBreaks;

package/dist/helpers/resolveMessageTranslation.d.ts

@@ -0,0 +1,34 @@
+import { IMessage } from '../types/types';
+export interface ResolvedMessageTranslation {
+    /**
+     * Whether this message would need translating for this reader at all: a
+     * known source language whose base differs from the reader's, and actual
+     * translatable text. False means there is nothing to reveal, no matter
+     * what a host `onTranslate` or a translate service might otherwise find -
+     * a bare number, an emoji-only reaction, an untagged message, or a
+     * message already in the reader's language.
+     */
+    needsTranslation: boolean;
+    /**
+     * True when a real, non-identical translation is already attached to the
+     * message (`message.translations`) for this reader - safe to render with
+     * no network call at all.
+     */
+    hasTranslation: boolean;
+    originalText: string;
+    /** hasTranslation ? the translation : originalText - always safe to render directly. */
+    displayText: string;
+}
+/**
+ * Resolve "what translation do we have for this message, for this reader" -
+ * pure, synchronous, no HTTP. This is the ONE place that reads
+ * `message.translations` and decides whether what it finds counts as a real
+ * translation.
+ *
+ * Auto mode (`useMessageTranslation`) and manual mode (`MessageTranslate`)
+ * both call this instead of keeping their own copies of the lookup, so they
+ * can never drift into showing different things for the same message: manual
+ * mode's click-to-reveal shows exactly what auto mode would have rendered
+ * automatically, because both ask this same function the same question.
+ */
+export declare const resolveMessageTranslation: (message: Pick<IMessage, "body" | "langSource" | "translations">, readerLocale?: string) => ResolvedMessageTranslation;

package/dist/helpers/roomImageGallery.d.ts

@@ -0,0 +1,53 @@
+import { IMessage, ModalFile } from '../types/types';
+/**
+ * One navigable entry in the media viewer's gallery.
+ *
+ * Shaped as a `ModalFile` (plus a render key) on purpose: navigating is just
+ * `dispatch(setActiveFile(entry))`, so every downstream consumer - the
+ * download action, the secure `?ft=` token treatment, the alt text - keeps
+ * reading exactly the fields it read when a single file was opened by hand.
+ */
+export interface GalleryImage extends ModalFile {
+    /** Stable per message+slot, so two identical URLs are still two entries. */
+    key: string;
+}
+/**
+ * The gallery the lightbox pages through.
+ *
+ * Scope, deliberately narrow and honest: **image attachments carried by the
+ * messages currently in the store for this room, in chronological order**.
+ * That is not "every image ever posted here":
+ *
+ * - History is paged from MAM. Only what has been loaded so far is here, so
+ *   the gallery grows as the user (or the background preloader) pulls older
+ *   history in. The counter re-renders with it.
+ * - MessageList's render window (120 initial / 60 per step) does NOT bound
+ *   this: the window controls how many messages are *mounted*, while the
+ *   store keeps every loaded message. So the gallery routinely contains
+ *   images that are not currently in the DOM, which is what makes paging
+ *   past the top of the viewport work at all.
+ * - `useMyFiles` (/v2/files) was the other candidate source and is the wrong
+ *   one: that endpoint lists the *caller's own* uploads with no server-side
+ *   room filter, so it would show the viewer their own files from other
+ *   rooms while hiding every image anybody else posted in this one.
+ *
+ * Non-images (video, PDF, audio, arbitrary files) are excluded, so opening a
+ * PDF simply produces an empty gallery and no navigation chrome.
+ */
+export declare const collectRoomImages: (messages?: Partial<IMessage>[] | null) => GalleryImage[];
+/**
+ * Position of the open file inside the gallery, or -1 when it is not part of
+ * it (a PDF, a video, a file opened from the Files panel of another room).
+ *
+ * Matching is by URL with the secure-file `?ft=` token stripped from both
+ * sides: it is the one field every entry point fills in, but the URL that
+ * reached the store when the bubble was clicked can already carry a token
+ * (they are minted per viewer and expire in about an hour) while the copy
+ * read back from the message does not. Comparing the raw strings therefore
+ * failed for exactly the secure rooms this feature has to work in.
+ *
+ * Two posts of the same URL collapse onto the first: a duplicate image is
+ * the same picture, so paging to it twice would only look like the arrows
+ * were stuck.
+ */
+export declare const findGalleryIndex: (images: GalleryImage[], activeFile?: ModalFile | null) => number;

package/dist/helpers/secureFileUrl.d.ts

@@ -1,4 +1,12 @@
 export declare const isSecureFileUrl: (url?: string | null) => boolean;
 export declare const appendFileToken: (url: string | null | undefined, fileToken: string | null | undefined) => string;
+/**
+ * The same URL with any `?ft=` token removed, for comparing two references
+ * to the same file. Tokens are per-viewer and short-lived, so the URL a
+ * message bubble handed the store can carry one while the copy read back
+ * from the message's attachments does not (or carries an older one). Only
+ * the token-free form is a stable identity.
+ */
+export declare const withoutFileToken: (url?: string | null) => string;
 export declare const withFileToken: (url?: string | null) => string;
 export declare const requestFileTokenRecovery: () => Promise<boolean>;

package/dist/helpers/sendFailureWatchdog.d.ts

@@ -0,0 +1,62 @@
+/**
+ * How long a send may stay unacknowledged before we show the sender a
+ * "not delivered" state with a retry control.
+ *
+ * Why 12s, and not something snappier:
+ *
+ *  - The only acknowledgement this protocol gives us is the MUC reflecting
+ *    our own message back (`addRoomMessage` clears `pending` on it). There
+ *    is no delivery receipt, so "no echo yet" is the ONLY failure signal we
+ *    have, and it is a weak one - it is equally consistent with a healthy
+ *    but slow send.
+ *  - A healthy echo lands in ~100-300ms. xmppClient's own SLA warning fires
+ *    at a p95 click-to-echo of 1500ms (`sendSlaWarningThresholdMs`), i.e.
+ *    the client already considers 1.5s the outer edge of normal. 12s is 8x
+ *    that outer edge.
+ *  - The catch-up probe (`scheduleAckCatchup`, 2500ms) re-asserts presence
+ *    and pulls MAM when the echo is missing. That probe gets a full ~9.5s
+ *    to reconcile the message before this watchdog is allowed to call it
+ *    failed, so the common "our presence silently dropped" case is repaired
+ *    without the user ever seeing a failure.
+ *  - Bursts and long messages are covered by WHERE the timer is armed, not
+ *    by its length: it starts when the optimistic bubble appears and is
+ *    re-armed on retry, while the send queue is serialised. A message stuck
+ *    behind a burst still has its own 12s window measured from the moment
+ *    the user could first see it.
+ *
+ * Erring long is deliberate. React Native defect #31 (26.7.1) shipped the
+ * opposite trade: a trigger-happy timeout showed accepted messages as
+ * failed and the resulting retries delivered them twice. A late "failed" is
+ * a cosmetic annoyance; an early one produces duplicates for the recipient.
+ */
+export declare const SEND_FAILURE_TIMEOUT_MS = 12000;
+/**
+ * Sanity check, not a runtime knob: the watchdog must never be able to fire
+ * before the catch-up probe has had a chance to repair the send.
+ */
+export declare const SEND_FAILURE_MIN_TIMEOUT_MS: number;
+/** True while a manual retry for this message id is on the wire. */
+export declare const isSendRetryInFlight: (messageId: string) => boolean;
+/**
+ * Claims the retry slot for a message id. Returns false when another retry
+ * for the same id already holds it, which is what makes a double-tap (or a
+ * second component instance rendering the same message) send exactly once.
+ */
+export declare const beginSendRetry: (messageId: string) => boolean;
+export declare const endSendRetry: (messageId: string) => void;
+export declare const clearSendFailureWatchdog: (messageId?: string) => void;
+export declare const clearAllSendFailureWatchdogs: () => void;
+/** Whether the store currently shows this message as failed-to-send. */
+export declare const isMessageMarkedFailed: (roomJID: string, messageId: string) => boolean;
+/**
+ * Arms the "this send was never acknowledged" timer for one message.
+ *
+ * Re-arming for the same id replaces the previous timer rather than adding
+ * a second one, so a retry cannot leave two watchdogs racing on one message.
+ */
+export declare const armSendFailureWatchdog: (params: {
+    roomJID: string;
+    messageId: string;
+    body: string;
+    timeoutMs?: number;
+}) => void;

package/dist/helpers/transformTranslatations.d.ts

@@ -1,4 +1,4 @@
-interface Translation {
+export interface Translation {
     translatedText: string;
     language: string;
     languageName: string;
@@ -7,4 +7,3 @@ export interface TranslationObject {
     [language: string]: Translation;
 }
 export declare const transformArrayToObject: (array: Translation[]) => TranslationObject;
-export {};

package/dist/hooks/pushSubscriptionSweep.d.ts

@@ -0,0 +1,41 @@
+/**
+ * pushSubscriptionSweep.ts
+ *
+ * Pure, hook-free worker pool for usePushNotifications' per-room push
+ * subscription sweep. Kept in its own module (no React, no Firebase, no
+ * Redux imports) so it can be unit tested without pulling in the heavy
+ * side effects those modules carry at import time.
+ */
+export type PushSubscribeResult = {
+    ok: boolean;
+    reason?: string;
+    message?: string;
+};
+export type PushSweepGuards = {
+    getStatus: (jid: string) => string | undefined;
+    getRetryAt: (jid: string) => number | undefined;
+    isInFlight: (jid: string) => boolean;
+    markInFlight: (jid: string) => void;
+    clearInFlight: (jid: string) => void;
+    setStatus: (jid: string, status: string) => void;
+    subscribe: (jid: string) => Promise<PushSubscribeResult>;
+    onSubscribed?: (jid: string) => void;
+    onFailed?: (jid: string, message?: string) => void;
+};
+/** Number of rooms subscribed to push in parallel during a sweep. */
+export declare const PUSH_SWEEP_CONCURRENCY = 4;
+/**
+ * Sweeps `roomJIDs` for push subscription, previously a strictly serial
+ * for-loop with a fixed 100ms sleep between every room (so N rooms took at
+ * least N*100ms even though subscribing does not depend on room order).
+ * This runs a small worker pool instead, bounded by `concurrency`, while
+ * keeping every existing guard intact: status checks (subscribed / pending
+ * / blocked / error are skipped), the roomRetryAtRef backoff, and the
+ * roomSubscribeInFlightRef in-flight lock. The caller owns the
+ * roomProcessRunningRef / lastRoomsHashRef gates around the whole sweep.
+ *
+ * `roomJIDs` are processed by a fixed-size pool of workers pulling from a
+ * shared index, so at most `concurrency` subscribe calls are in flight at
+ * once regardless of how many rooms need syncing.
+ */
+export declare const sweepPushSubscriptions: (roomJIDs: string[], guards: PushSweepGuards, concurrency?: number) => Promise<void>;

package/dist/hooks/useChatOpenPhase.d.ts

@@ -0,0 +1,21 @@
+export type ChatOpenPhase = 'opening' | 'settled';
+/**
+ * Collapses "is this room's history still loading" into one phase that only
+ * ever moves forward, once, for a given room key: 'opening' -> 'settled'.
+ * It never reports 'opening' again for the same key once it has settled -
+ * ChatRoom relies on that to stop the Loader/placeholder pane from
+ * oscillating while a room opens (see the flicker this hook exists to
+ * fix). A settled-but-empty room can still legitimately start rendering
+ * messages later (a live message arrives) - that is not this hook's
+ * concern; callers derive that from their own `hasMessages`, this hook only
+ * owns whether the opening UI is still allowed to show.
+ *
+ * `roomKey` resets the latch: pass the active room's JID (or null). The
+ * reset happens synchronously during render (React's "adjust state while
+ * rendering" pattern), so switching rooms - even quickly, back and forth -
+ * never paints a frame of the previous room's settled state under the new
+ * room's key, and never leaves a stale debounce timer running against the
+ * new key (the effect below is keyed on `roomKey` too, so its cleanup
+ * clears the old timer before the new one can be scheduled).
+ */
+export declare const useChatOpenPhase: (roomKey: string | null, isLoadingSignal: boolean) => ChatOpenPhase;

package/dist/hooks/useChatWrapperInit.d.ts

@@ -17,5 +17,6 @@ interface useChatWrapperInitResult {
 }
 export declare const resolveLegacyTranslatesLangSource: (translatesConfig?: IConfig["translates"]) => Iso639_1Codes | undefined;
 export declare const resolveExternalReaderLocaleLangSource: (readerLocale?: string) => Iso639_1Codes | undefined;
+export declare const isStatusConnectionLost: (status?: string | null) => boolean;
 declare const useChatWrapperInit: ({ roomJID, wasAutoSelected, config, }: useChatWrapperInitProps) => useChatWrapperInitResult;
 export default useChatWrapperInit;

package/dist/hooks/useDelayedAction.d.ts

@@ -0,0 +1,22 @@
+export interface DelayedActionState {
+    /** Call instead of the real close/dismiss handler. */
+    requestAction: () => void;
+    /** True from the moment `requestAction` is called until `action` actually
+     *  runs - apply the exit animation while this is true. */
+    isPending: boolean;
+}
+/**
+ * For a component that closes ITSELF (a modal that owns `isOpen` locally,
+ * or one that only gets an `onClose` callback with no boolean to watch):
+ * wraps `action` so calling `requestAction()` plays out the exit animation
+ * first and only invokes the real `action` once it has finished, instead of
+ * unmounting on the same tick the user clicked close.
+ *
+ * This works because the component stays mounted for exactly as long as its
+ * parent's render condition stays true, and that condition usually depends
+ * on the very state `action` is about to change - delaying the call delays
+ * the unmount for free, no separate "still rendering while closing" flag
+ * needed at the parent. See `useExitTransition` for the opposite case: the
+ * parent owns `isOpen` and the child has no closing callback to intercept.
+ */
+export declare function useDelayedAction(action: () => void, durationMs: number): DelayedActionState;

package/dist/hooks/useExclusiveRightPane.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Keeps the chat to at most three columns.
+ *
+ * Two different things want to be the right-hand column: the thread view
+ * (`Thread/ThreadWrapper`) and the profile/settings panel
+ * (`Modals/SidePanel`). Letting both take space at once gives four columns
+ * and squeezes the conversation into nothing, so the rule is the one most
+ * products use: THE ONE OPENED LAST WINS, and the other closes. Opening a
+ * profile while reading a thread puts the profile there and drops back to the
+ * room's messages; opening a thread from a message while a profile is open
+ * closes the profile. Either way, dismissing the survivor leaves the plain
+ * two-column chat, never a half-state.
+ *
+ * The tie-break for "both already open on the first render" (a remount with
+ * persisted state, not something a click can produce) is to close the panel:
+ * the thread is the reading context the user was in, the panel is chrome.
+ */
+interface UseExclusiveRightPaneOptions {
+    threadOpen: boolean;
+    panelOpen: boolean;
+    closeThread: () => void;
+    closePanel: () => void;
+}
+export declare const useExclusiveRightPane: ({ threadOpen, panelOpen, closeThread, closePanel, }: UseExclusiveRightPaneOptions) => void;
+export default useExclusiveRightPane;

package/dist/hooks/useExitTransition.d.ts

@@ -0,0 +1,24 @@
+export interface ExitTransitionState {
+    /** Whether the caller should still render the element at all. */
+    shouldRender: boolean;
+    /** True for the window between `isOpen` going false and the element
+     *  actually leaving the DOM - apply the exit animation while this is true. */
+    isExiting: boolean;
+}
+/**
+ * Keeps an element mounted for `durationMs` after `isOpen` flips to false, so
+ * a CSS exit animation has time to play instead of the element vanishing on
+ * the same frame the state changes.
+ *
+ * This is the "someone else decides when I close" half of the presence
+ * story - the caller owns `isOpen` (Redux state, a prop, ...) and this hook
+ * just tells it how long to keep rendering. For a component that closes
+ * itself (a modal with its own local open flag, reacting to its own close
+ * button), prefer `useDelayedAction` instead: it lets the component play the
+ * animation and only THEN flip its own state, which is simpler when there is
+ * no external boolean to watch.
+ *
+ * Respects `prefers-reduced-motion`: when set, the element is removed on the
+ * same tick `isOpen` goes false, same as if `durationMs` were 0.
+ */
+export declare function useExitTransition(isOpen: boolean, durationMs: number): ExitTransitionState;

package/dist/hooks/useFilesEndpointSupport.d.ts

@@ -0,0 +1,9 @@
+import { FilesEndpointSupport } from '../networking/api-requests/files.api';
+/**
+ * Whether the current user's backend actually has /v2/files. Starts
+ * 'unknown' and flips to 'supported'/'unsupported' the first time a real
+ * files list request resolves (see files.api.ts) - there's no separate probe
+ * request, this just observes the outcome of whatever the Files panel itself
+ * already does.
+ */
+export declare function useFilesEndpointSupport(): FilesEndpointSupport;

package/dist/hooks/useGetNewArchRoom.d.ts

@@ -1,3 +1,5 @@
 import { ApiRoom } from '../types/types';
-declare const useGetNewArchRoom: () => (client: any, config: any) => Promise<ApiRoom[]>;
+declare const useGetNewArchRoom: () => (client: any, config: any, options?: {
+    force?: boolean;
+}) => Promise<ApiRoom[]>;
 export default useGetNewArchRoom;

package/dist/hooks/useInView.d.ts

@@ -0,0 +1,17 @@
+interface UseInViewOptions {
+    /** Start work slightly before the element scrolls into view. */
+    rootMargin?: string;
+    /** Once true, stay true - re-rendering a thumbnail on every scroll pass is waste. */
+    once?: boolean;
+}
+/**
+ * Viewport gate for expensive per-message work (PDF rendering today).
+ * Environments without IntersectionObserver - jsdom, older Safari - report
+ * "in view" immediately, which degrades to the previous eager behaviour
+ * rather than to a blank card.
+ */
+export declare const useInView: <T extends Element>({ rootMargin, once, }?: UseInViewOptions) => {
+    ref: import('react').MutableRefObject<T>;
+    inView: boolean;
+};
+export {};

package/dist/hooks/useMentionComposer.d.ts

@@ -0,0 +1,45 @@
+import { IMentionSpan, RoomMember } from '../types/types';
+import { MentionCandidate } from '../helpers/mentions';
+export declare const MENTION_INLINE_LIMIT = 5;
+interface UseMentionComposerParams {
+    roomMembers: RoomMember[];
+    selfId?: string;
+}
+interface DropdownState {
+    start: number;
+    query: string;
+}
+/**
+ * Tracks @-mention spans and the inline autocomplete dropdown for a plain
+ * <input>/<textarea> based message composer (see SendInput.tsx). Text
+ * editing and caret placement stay owned by the caller (a controlled React
+ * input) - this hook only computes the *derived* state: which mention spans
+ * still hold after an edit, and what the dropdown should show.
+ */
+export declare const useMentionComposer: ({ roomMembers, selfId, }: UseMentionComposerParams) => {
+    mentionSpans: IMentionSpan[];
+    setMentionSpans: import('react').Dispatch<import('react').SetStateAction<IMentionSpan[]>>;
+    dropdown: DropdownState;
+    isDropdownOpen: boolean;
+    candidates: MentionCandidate[];
+    visibleCandidates: MentionCandidate[];
+    hasOverflow: boolean;
+    highlightedIndex: number;
+    setHighlightedIndex: import('react').Dispatch<import('react').SetStateAction<number>>;
+    moveHighlight: (delta: number) => void;
+    overflowOpen: boolean;
+    setOverflowOpen: import('react').Dispatch<import('react').SetStateAction<boolean>>;
+    resetMentions: () => void;
+    closeDropdown: () => void;
+    handleTextChange: (oldText: string, newText: string, caret: number) => void;
+    selectCandidate: (candidate: MentionCandidate, text: string, caretAtSelection: number) => {
+        text: string;
+        caret: number;
+    } | null;
+    handleBackspace: (text: string, selectionStart: number, selectionEnd: number) => {
+        text: string;
+        caret: number;
+    } | null;
+};
+export type UseMentionComposerReturn = ReturnType<typeof useMentionComposer>;
+export {};

package/dist/hooks/useMessageHeapState.d.ts

@@ -1,4 +1,4 @@
 export declare const useMessageHeapState: () => {
-    queue: import('../types/types').IMessage[];
+    queue: import('../main').IMessage[];
     idSet: Set<string>;
 };

package/dist/hooks/useMessageTranslation.d.ts

@@ -16,9 +16,10 @@ export interface MessageTranslationState {
  * `<translate source="xx"/>` (see sendTextMessageWithTranslateTag) and
  * whatever process attaches actual translations does so server-side,
  * landing on `message.translations` when the stanza is parsed (see
- * getDataFromXml). This function only ever reads that - it never calls a
- * translation service itself, so there's nothing to fail when one isn't
- * reachable, and nothing to await.
+ * getDataFromXml). This hook is a thin wrapper around
+ * `resolveMessageTranslation` (the shared lookup manual mode also uses) - it
+ * never calls a translation service itself, so there's nothing to fail when
+ * one isn't reachable, and nothing to await.
  *
  * A message sent before the sender had translate-sending turned on simply
  * never got tagged, so it has no translation to show - not an error, just

package/dist/hooks/useModalDismiss.d.ts

@@ -0,0 +1,27 @@
+type DismissLayerKind = 'modal' | 'menu';
+export declare const FOCUSABLE_SELECTOR = "a[href], button:not([disabled]), input:not([disabled]), select:not([disabled]), textarea:not([disabled]), [tabindex]:not([tabindex=\"-1\"])";
+export interface UseModalDismissOptions {
+    onClose?: () => void;
+    enabled?: boolean;
+    /** Ref to the dialog/menu container; used for initial focus. */
+    containerRef?: React.RefObject<HTMLElement | null>;
+    /**
+     * 'modal' (default) stacks; 'menu' is exclusive, see the note above.
+     */
+    kind?: DismissLayerKind;
+    /**
+     * Close when a press lands outside the layer. Off by default: modals own
+     * a full-screen overlay that already handles this.
+     */
+    closeOnOutsidePress?: boolean;
+    /**
+     * Extra elements counted as "inside" for outside-press dismissal, on top
+     * of `containerRef`. A menu passes its trigger here: the trigger's own
+     * click is the toggle's business, and letting the document listener close
+     * the menu first would make the trigger look like it never closes (the
+     * toggle would immediately re-open what the listener just shut).
+     */
+    insideRefs?: React.RefObject<HTMLElement | null>[];
+}
+export declare const useModalDismiss: ({ onClose, enabled, containerRef, kind, closeOnOutsidePress, insideRefs, }: UseModalDismissOptions) => void;
+export default useModalDismiss;