@remit/web-client 0.0.325 → 0.0.326

package/dist/src/routing/reply.js

@@ -0,0 +1,238 @@
+import { useNavigate, useParams, useSearch } from "@tanstack/react-router";
+import { useCallback, useMemo } from "react";
+import { z } from "zod";
+import { withoutComposeSeed } from "../lib/mail-search";
+import { useBrowsedList } from "./browsed-list";
+import { useRetainOpenPanels } from "./fragment";
+/**
+ * The three ways to answer a message. They are one path param rather than three
+ * literal routes, so the reply is one address shape and the mode is a value the
+ * composer reads.
+ */
+export const replyModes = ["reply", "reply-all", "forward"];
+const replyModeSchema = z.enum(replyModes);
+/**
+ * The reply route under each list that can have a conversation open. The outbox
+ * has no thread segment, so it has no reply either.
+ *
+ * The draft is an optional segment of the same route rather than a child of it,
+ * for the reason `compose/{-$outboxMessageId}` is: the first autosave adopts
+ * the id it created while the reader is mid-sentence, and a child route would
+ * unmount the composer to record it.
+ */
+const BRIEF_REPLY = "/mail/brief/$threadId/$messageId/$mode/{-$outboxMessageId}";
+const FLAGGED_REPLY = "/mail/flagged/$threadId/$messageId/$mode/{-$outboxMessageId}";
+const MAILBOX_REPLY = "/mail/$mailboxId/$threadId/$messageId/$mode/{-$outboxMessageId}";
+/**
+ * The reply match, if the address has one. Each `from` names a real route, so a
+ * segment that does not exist fails to compile.
+ *
+ * A path matches one list at a time, so at most one of these answers.
+ */
+function useReplyParams() {
+    const brief = useParams({ from: BRIEF_REPLY, shouldThrow: false });
+    const flagged = useParams({ from: FLAGGED_REPLY, shouldThrow: false });
+    const mailbox = useParams({ from: MAILBOX_REPLY, shouldThrow: false });
+    return brief ?? flagged ?? mailbox;
+}
+function useReplySeed() {
+    const brief = useSearch({ from: BRIEF_REPLY, shouldThrow: false });
+    const flagged = useSearch({ from: FLAGGED_REPLY, shouldThrow: false });
+    const mailbox = useSearch({ from: MAILBOX_REPLY, shouldThrow: false });
+    return (brief ?? flagged ?? mailbox)?.body;
+}
+const seededSearch = (seed) => (prev) => seed === undefined
+    ? withoutComposeSeed(prev)
+    : { ...withoutComposeSeed(prev), body: seed.body };
+/**
+ * The reply surface the address names, or none.
+ *
+ * The mode and the message it answers are both segments, so a reply cannot
+ * exist without a source and neither fact has a second owner. The draft is the
+ * segment under them, so a reload comes back to what was being written instead
+ * of starting a second draft beside it.
+ */
+export function useReplySurface() {
+    const params = useReplyParams();
+    const seedBody = useReplySeed();
+    return useMemo(() => {
+        if (!params)
+            return undefined;
+        const mode = replyModeSchema.safeParse(params.mode);
+        if (!mode.success)
+            return { kind: "unknown", segment: params.mode };
+        return {
+            kind: "reply",
+            mode: mode.data,
+            threadId: params.threadId,
+            sourceMessageId: params.messageId,
+            outboxMessageId: params.outboxMessageId,
+            seed: seedBody === undefined ? undefined : { body: seedBody },
+        };
+    }, [params, seedBody]);
+}
+/**
+ * Whether a composer is open inside the conversation.
+ *
+ * The list's keyboard layer suspends on this: with a reply up, r, R and f are
+ * the composer's business, and a list still answering them would restart the
+ * reply on screen — or aim one at whichever row the cursor happens to be on.
+ * A segment naming no mode does not count: there is no composer to protect, and
+ * r is then the way out of a hand-typed address.
+ */
+export function useIsReplying() {
+    return useReplySurface()?.kind === "reply";
+}
+/**
+ * Where a reply opens: under the message, in the list the reader is browsing.
+ *
+ * The brief is the fallback for the reason compose falls back to it — it always
+ * exists and always mounts the conversation — so the frame before a folder id
+ * resolves opens a composer rather than reporting that it cannot.
+ */
+function replyTarget(list, mailboxId, target, outboxMessageId) {
+    if (list === "flagged")
+        return { to: FLAGGED_REPLY, params: { ...target, outboxMessageId } };
+    if (list === "mailbox" && mailboxId)
+        return {
+            to: MAILBOX_REPLY,
+            params: { ...target, mailboxId, outboxMessageId },
+        };
+    return { to: BRIEF_REPLY, params: { ...target, outboxMessageId } };
+}
+/**
+ * The draft a new reply address inherits: the one already being written, when
+ * the reply on screen answers the same message.
+ *
+ * Reply All over a reply is the same message being written — the recipients
+ * change and the text does not — so the draft segment travels with the mode.
+ * Dropping it would say "a different document" to the composer, which blanks
+ * the fields and leaves the draft reachable only from the Outbox. A different
+ * message is a different reply and inherits nothing.
+ */
+function inheritedDraft(open, target) {
+    if (open?.kind !== "reply")
+        return undefined;
+    if (open.threadId !== target.threadId)
+        return undefined;
+    if (open.sourceMessageId !== target.messageId)
+        return undefined;
+    return open.outboxMessageId;
+}
+/**
+ * Answer a message: the mode and the turn it answers, as one navigation.
+ *
+ * The message travels with the mode, so replying from a row the address had not
+ * named yet opens the conversation on it and the composer over it in the same
+ * transition — there is no "open it first, then reply" for the second half to
+ * be dropped from.
+ *
+ * A push, so Back leaves the reply and returns the message it was written
+ * under, and the query travels with it.
+ */
+export function useOpenReply() {
+    const navigate = useNavigate();
+    const retainPanels = useRetainOpenPanels();
+    const { list, mailboxId } = useBrowsedList();
+    const open = useReplySurface();
+    return useCallback((target, seed) => {
+        navigate({
+            ...replyTarget(list, mailboxId, target, seed === undefined ? inheritedDraft(open, target) : undefined),
+            search: seededSearch(seed),
+            hash: retainPanels,
+        });
+    }, [navigate, retainPanels, list, mailboxId, open]);
+}
+/**
+ * Answer the conversation a list has open, from the segments naming it.
+ *
+ * The thread and the turn being answered are both in the path, so this is the
+ * address answering for itself: a listing row still in flight cannot make the
+ * verbs wait, and a thread request that fails outright cannot take them away.
+ * Reading the thread id back off a fetched row was the same fact in two places.
+ *
+ * A plain function rather than a hook, because every list already holds both
+ * values and the router state behind them. Reaching for them again here would
+ * subscribe each pane to the router a second time, and a pane re-rendering on
+ * every address change is felt by everything it wraps.
+ *
+ * `messageId` is the one thing the address can be silent about — a bare thread
+ * address leaves which turn answers for the conversation to the thread, so the
+ * caller passes the newest one once it knows. Absent until then, which is the
+ * toolbar's to explain.
+ */
+export function replyToThread(openReply, threadId, messageId) {
+    if (!threadId || !messageId)
+        return undefined;
+    return (mode) => openReply({ threadId, messageId, mode });
+}
+/**
+ * Record the draft the reply just created, in the address.
+ *
+ * A replace, and every panel left alone: the reader started one message, so the
+ * draft arriving under it is neither another step of history nor a move away
+ * from what they have open over the conversation.
+ */
+export function useAdoptReplyDraft() {
+    const navigate = useNavigate();
+    const { list, mailboxId } = useBrowsedList();
+    const surface = useReplySurface();
+    return useCallback((outboxMessageId) => {
+        if (surface?.kind !== "reply")
+            return;
+        navigate({
+            ...replyTarget(list, mailboxId, {
+                threadId: surface.threadId,
+                messageId: surface.sourceMessageId,
+                mode: surface.mode,
+            }, outboxMessageId),
+            search: seededSearch(undefined),
+            hash: true,
+            replace: true,
+        });
+    }, [navigate, list, mailboxId, surface]);
+}
+/**
+ * Close the reply, landing back on the message it was answering.
+ *
+ * A push, like opening it: dismissing a surface moves the reader on, and Back
+ * is how they undo that. The conversation stayed matched behind the reply, so
+ * this drops the segments below it rather than rebuilding an address.
+ */
+export function useCloseReply() {
+    const navigate = useNavigate();
+    const retainPanels = useRetainOpenPanels();
+    const { list, mailboxId } = useBrowsedList();
+    const params = useReplyParams();
+    return useCallback(() => {
+        if (!params)
+            return;
+        const search = seededSearch(undefined);
+        const hash = retainPanels;
+        const message = { threadId: params.threadId, messageId: params.messageId };
+        if (list === "flagged") {
+            navigate({
+                to: "/mail/flagged/$threadId/$messageId",
+                params: message,
+                search,
+                hash,
+            });
+            return;
+        }
+        if (list === "mailbox" && mailboxId) {
+            navigate({
+                to: "/mail/$mailboxId/$threadId/$messageId",
+                params: { ...message, mailboxId },
+                search,
+                hash,
+            });
+            return;
+        }
+        navigate({
+            to: "/mail/brief/$threadId/$messageId",
+            params: message,
+            search,
+            hash,
+        });
+    }, [navigate, retainPanels, list, mailboxId, params]);
+}

package/dist/src/routing/search-field.d.ts

@@ -0,0 +1,45 @@
+export interface SearchField {
+    /** The live field text, which every search surface binds. */
+    searchInput: string;
+    /** The debounced query the search APIs run and the mirror writes. */
+    committedQuery: string;
+    /** The view the field is searching (`lib/mail-route.ts`). */
+    viewKey: string;
+    /** Every write to the field — typed, cleared, or a chip edited. */
+    setSearchInput: (query: string) => void;
+}
+/**
+ * The one search field, held by the /mail shell so it outlives every child
+ * route, and the query it commits.
+ *
+ * Within a view the URL's `q` seeds it and is a one-directional write target:
+ * the committed value drives the search APIs and each list's `useSearchMirror`
+ * writes it back. Across views the URL wins again — search is a mode of the
+ * view it was typed in, so leaving that view re-seeds the field from wherever
+ * the reader lands (#47), empty when the sidebar dropped `q` and the carried
+ * query when the scope chip sent them to the brief to search everything.
+ *
+ * The re-seed is adjusted during render, not in an effect: React's documented
+ * "adjusting state when a prop changes" pattern, so nothing is painted carrying
+ * the previous view's text. An effect would commit one frame with the stale
+ * query in it, which the mirror then has to be defended against.
+ *
+ * Text carries the view it was typed in, rather than the field simply taking
+ * whatever the last render's view key was (#808). The address moves a render
+ * ahead of React — a keystroke and the view change it followed arrive in the
+ * same render, and the re-seed cannot tell them apart from what it has on
+ * screen. Stamping the view at the keystroke, off the address the router has
+ * already committed, says which of the two came second: type into the field
+ * once the address names the next mailbox and that text is the new view's, not
+ * a leftover of the one being left. Without it a query typed in that window was
+ * wiped in the render that followed, and since the field then held nothing the
+ * mirror had nothing to write — the query never reached the URL at all.
+ *
+ * Which view and which query both come off the committed address, never one
+ * from the address and the other from the matched route. The matches swap a
+ * render behind the address, so mixing the two reads the destination's view
+ * against the outgoing list's `q` and re-seeds the field with the query the
+ * reader has just navigated away from — the stamp then calls that text the new
+ * view's, and nothing reconsiders it (#47).
+ */
+export declare function useSearchField(): SearchField;

package/dist/src/routing/search-field.js

@@ -0,0 +1,67 @@
+import { useRouter, useRouterState } from "@tanstack/react-router";
+import { useCallback, useState } from "react";
+import { useDebouncedValue } from "../hooks/useDebouncedValue";
+import { addressQuery, mailViewKey } from "../lib/mail-route";
+import { committedSearchQuery, searchInputForView } from "../lib/search-view";
+/**
+ * The one search field, held by the /mail shell so it outlives every child
+ * route, and the query it commits.
+ *
+ * Within a view the URL's `q` seeds it and is a one-directional write target:
+ * the committed value drives the search APIs and each list's `useSearchMirror`
+ * writes it back. Across views the URL wins again — search is a mode of the
+ * view it was typed in, so leaving that view re-seeds the field from wherever
+ * the reader lands (#47), empty when the sidebar dropped `q` and the carried
+ * query when the scope chip sent them to the brief to search everything.
+ *
+ * The re-seed is adjusted during render, not in an effect: React's documented
+ * "adjusting state when a prop changes" pattern, so nothing is painted carrying
+ * the previous view's text. An effect would commit one frame with the stale
+ * query in it, which the mirror then has to be defended against.
+ *
+ * Text carries the view it was typed in, rather than the field simply taking
+ * whatever the last render's view key was (#808). The address moves a render
+ * ahead of React — a keystroke and the view change it followed arrive in the
+ * same render, and the re-seed cannot tell them apart from what it has on
+ * screen. Stamping the view at the keystroke, off the address the router has
+ * already committed, says which of the two came second: type into the field
+ * once the address names the next mailbox and that text is the new view's, not
+ * a leftover of the one being left. Without it a query typed in that window was
+ * wiped in the render that followed, and since the field then held nothing the
+ * mirror had nothing to write — the query never reached the URL at all.
+ *
+ * Which view and which query both come off the committed address, never one
+ * from the address and the other from the matched route. The matches swap a
+ * render behind the address, so mixing the two reads the destination's view
+ * against the outgoing list's `q` and re-seeds the field with the query the
+ * reader has just navigated away from — the stamp then calls that text the new
+ * view's, and nothing reconsiders it (#47).
+ */
+export function useSearchField() {
+    const router = useRouter();
+    const viewKey = useRouterState({
+        select: (state) => mailViewKey(state.location.pathname),
+    });
+    const urlQuery = useRouterState({
+        select: (state) => addressQuery(state.location.search),
+    });
+    const [searchInput, setInput] = useState(urlQuery);
+    const debouncedSearchInput = useDebouncedValue(searchInput, 200);
+    const [typedInView, setTypedInView] = useState(viewKey);
+    if (typedInView !== viewKey) {
+        const seeded = searchInputForView(typedInView, viewKey, urlQuery);
+        setTypedInView(viewKey);
+        if (seeded !== undefined)
+            setInput(seeded);
+    }
+    const setSearchInput = useCallback((query) => {
+        setTypedInView(mailViewKey(router.state.location.pathname));
+        setInput(query);
+    }, [router]);
+    return {
+        searchInput,
+        committedQuery: committedSearchQuery(searchInput, debouncedSearchInput),
+        viewKey,
+        setSearchInput,
+    };
+}

package/dist/src/routing/search-mirror.d.ts

@@ -0,0 +1,63 @@
+/**
+ * The list the mirror writes to. Each list calls the hook with its own route,
+ * so the query lands on the list rather than on whatever is open below it.
+ */
+export type SearchMirrorTarget = {
+    to: "/mail/brief" | "/mail/flagged" | "/mail/outbox";
+} | {
+    to: "/mail/$mailboxId";
+    params: {
+        mailboxId: string;
+    };
+};
+/**
+ * Mirrors the settled search into the URL so links are shareable and a refresh
+ * restores the query.
+ *
+ * Within a view this is one-directional — the URL is not read back into state,
+ * so there is no sync loop — and it writes only once the debounce agrees with
+ * the field, so a query arriving by URL is never overwritten mid-debounce, and
+ * the query the user just left behind is never written onto the view they landed
+ * on (`shouldMirrorQuery`).
+ *
+ * It watches the URL as well as the field, so a settled query that the address
+ * stops agreeing with is written again rather than left (#808). Typing lands
+ * more than one navigation — the debounce settles mid-word, and the word is
+ * finished while that write is still in flight — and the two can commit out of
+ * order, leaving the address on the prefix. Comparing against the URL without
+ * re-running on it made that final: the field said `invoice`, the address said
+ * `invo`, and nothing was left to disagree with. Re-running cannot start a
+ * loop, because every write makes the URL equal the committed query and the
+ * next run has nothing to do. The `q` it compares against is the committed
+ * address's, the same place the pathname below comes from: the matched route
+ * answers with the outgoing list's query for a render after the address has
+ * moved on, and a mirror reading one from each would write against a URL that
+ * no longer exists.
+ *
+ * It also writes only while the reader is still on this list. A list stays
+ * mounted, effects and all, until the list they navigated to is ready to paint,
+ * and by then the address is already the new one — so a debounce settling in
+ * that window would fire a navigation to *this* list, superseding the load in
+ * flight and replacing the entry the reader had just pushed. They would click
+ * Inbox and land back on the brief.
+ *
+ * When a query *goes* active it also closes the reading pane (#539): an open
+ * message from the pre-search list is not meaningful in the search result set.
+ * The close is a navigation to the list route, which unmatches the thread that
+ * was open under it. Any other write keeps the address it found: mirroring a
+ * query the reader is editing, or clearing one, must not shut the conversation
+ * they are reading.
+ *
+ * Only on that transition, though — tapping a search result commits the same `q`
+ * with the open thread, so when the URL already says the query the conversation
+ * was opened under it (not a pre-search leftover) and must survive. The close
+ * otherwise raced the tap: the row shows before the debounce settles, so this
+ * mirror can land just after the open and undo it.
+ *
+ * A composer is not the pre-search list's leftover either. It is the reader's
+ * own unsent message, so a search started while it is up narrows the list
+ * behind it and leaves it standing. A reply, a reply-all and a forward hold
+ * unsent text the same way and are spared the same way. Both are read off the
+ * path, so neither has to be kept in step with the surface that is showing.
+ */
+export declare function useSearchMirror(target: SearchMirrorTarget): void;

package/dist/src/routing/search-mirror.js

@@ -0,0 +1,120 @@
+import { useNavigate, useRouterState } from "@tanstack/react-router";
+import { useEffect } from "react";
+import { useMailContext } from "../lib/mail-context";
+import { addressQuery } from "../lib/mail-route";
+import { shouldMirrorQuery } from "../lib/search-view";
+import { useIsComposing } from "./compose";
+import { useIsReplying } from "./reply";
+/**
+ * Mirrors the settled search into the URL so links are shareable and a refresh
+ * restores the query.
+ *
+ * Within a view this is one-directional — the URL is not read back into state,
+ * so there is no sync loop — and it writes only once the debounce agrees with
+ * the field, so a query arriving by URL is never overwritten mid-debounce, and
+ * the query the user just left behind is never written onto the view they landed
+ * on (`shouldMirrorQuery`).
+ *
+ * It watches the URL as well as the field, so a settled query that the address
+ * stops agreeing with is written again rather than left (#808). Typing lands
+ * more than one navigation — the debounce settles mid-word, and the word is
+ * finished while that write is still in flight — and the two can commit out of
+ * order, leaving the address on the prefix. Comparing against the URL without
+ * re-running on it made that final: the field said `invoice`, the address said
+ * `invo`, and nothing was left to disagree with. Re-running cannot start a
+ * loop, because every write makes the URL equal the committed query and the
+ * next run has nothing to do. The `q` it compares against is the committed
+ * address's, the same place the pathname below comes from: the matched route
+ * answers with the outgoing list's query for a render after the address has
+ * moved on, and a mirror reading one from each would write against a URL that
+ * no longer exists.
+ *
+ * It also writes only while the reader is still on this list. A list stays
+ * mounted, effects and all, until the list they navigated to is ready to paint,
+ * and by then the address is already the new one — so a debounce settling in
+ * that window would fire a navigation to *this* list, superseding the load in
+ * flight and replacing the entry the reader had just pushed. They would click
+ * Inbox and land back on the brief.
+ *
+ * When a query *goes* active it also closes the reading pane (#539): an open
+ * message from the pre-search list is not meaningful in the search result set.
+ * The close is a navigation to the list route, which unmatches the thread that
+ * was open under it. Any other write keeps the address it found: mirroring a
+ * query the reader is editing, or clearing one, must not shut the conversation
+ * they are reading.
+ *
+ * Only on that transition, though — tapping a search result commits the same `q`
+ * with the open thread, so when the URL already says the query the conversation
+ * was opened under it (not a pre-search leftover) and must survive. The close
+ * otherwise raced the tap: the row shows before the debounce settles, so this
+ * mirror can land just after the open and undo it.
+ *
+ * A composer is not the pre-search list's leftover either. It is the reader's
+ * own unsent message, so a search started while it is up narrows the list
+ * behind it and leaves it standing. A reply, a reply-all and a forward hold
+ * unsent text the same way and are spared the same way. Both are read off the
+ * path, so neither has to be kept in step with the surface that is showing.
+ */
+export function useSearchMirror(target) {
+    const navigate = useNavigate();
+    const { searchInput, searchQuery: committedQuery } = useMailContext();
+    const urlQuery = useRouterState({
+        select: (s) => addressQuery(s.location.search),
+    });
+    const pathname = useRouterState({ select: (s) => s.location.pathname });
+    const isComposing = useIsComposing();
+    const isReplying = useIsReplying();
+    const isWriting = isComposing || isReplying;
+    const { to } = target;
+    const mailboxId = "params" in target ? target.params.mailboxId : undefined;
+    const listPath = mailboxId ? `/mail/${mailboxId}` : to;
+    useEffect(() => {
+        const mayWrite = shouldMirrorQuery({
+            searchInput,
+            committedQuery,
+            urlQuery,
+            pathname,
+            listPath,
+        });
+        if (!mayWrite)
+            return;
+        const queryGoesActive = Boolean(committedQuery) && urlQuery !== committedQuery;
+        // A message being written is the reader's own, not a leftover of the list
+        // they were on, so a query going active narrows the list behind it and
+        // leaves it where it is.
+        const closesTheOpenSurface = queryGoesActive && !isWriting;
+        const search = (prev) => ({
+            ...prev,
+            q: committedQuery || undefined,
+        });
+        // A query is a mode of the view the reader is already in, so the panels
+        // they have up are not ones they navigated away from.
+        if (!closesTheOpenSurface) {
+            navigate({ to: ".", search, hash: true, replace: true });
+            return;
+        }
+        if (to === "/mail/$mailboxId") {
+            if (!mailboxId)
+                return;
+            navigate({
+                to,
+                params: { mailboxId },
+                search,
+                hash: true,
+                replace: true,
+            });
+            return;
+        }
+        navigate({ to, search, hash: true, replace: true });
+    }, [
+        searchInput,
+        committedQuery,
+        urlQuery,
+        navigate,
+        to,
+        mailboxId,
+        listPath,
+        pathname,
+        isWriting,
+    ]);
+}

package/dist/src/routing/search-navigation.d.ts

@@ -0,0 +1,16 @@
+/**
+ * Search everything, carrying the query.
+ *
+ * "Everything" is the daily brief — the cross-account view whose scope is
+ * nothing — so dropping the scope chip is a navigation rather than an edit of
+ * the query text: the chip mirrors the route (see `lib/search-scope.ts`), so
+ * editing the text would leave the chip up and the list still narrowed.
+ */
+export declare function useSearchEverything(): (query: string) => void;
+/**
+ * Narrow the search to one mailbox, carrying the query.
+ *
+ * The route is the scope, so the offer to look in Spam for what a global search
+ * held back goes to Spam rather than rewriting the query with an `in:` term.
+ */
+export declare function useScopeSearchToMailbox(): (mailboxId: string, query: string) => void;

package/dist/src/routing/search-navigation.js

@@ -0,0 +1,32 @@
+import { useNavigate } from "@tanstack/react-router";
+import { useCallback } from "react";
+/**
+ * Search everything, carrying the query.
+ *
+ * "Everything" is the daily brief — the cross-account view whose scope is
+ * nothing — so dropping the scope chip is a navigation rather than an edit of
+ * the query text: the chip mirrors the route (see `lib/search-scope.ts`), so
+ * editing the text would leave the chip up and the list still narrowed.
+ */
+export function useSearchEverything() {
+    const navigate = useNavigate();
+    return useCallback((query) => {
+        navigate({ to: "/mail/brief", search: { q: query || undefined } });
+    }, [navigate]);
+}
+/**
+ * Narrow the search to one mailbox, carrying the query.
+ *
+ * The route is the scope, so the offer to look in Spam for what a global search
+ * held back goes to Spam rather than rewriting the query with an `in:` term.
+ */
+export function useScopeSearchToMailbox() {
+    const navigate = useNavigate();
+    return useCallback((mailboxId, query) => {
+        navigate({
+            to: "/mail/$mailboxId",
+            params: { mailboxId },
+            search: { q: query || undefined },
+        });
+    }, [navigate]);
+}

package/dist/src/routing/sections.d.ts

@@ -0,0 +1,16 @@
+/**
+ * A top-level destination, as the sidebar and the keyboard name it. These are
+ * the moves that leave whatever the reader is on rather than open something
+ * under it, so they carry no panels and no query.
+ */
+export type AppSection = "brief" | "flagged" | "outbox" | "settings" | "accounts" | "importConfig";
+/** Go to a top-level section by name, so no caller writes a path. */
+export declare function useGoToSection(): (section: AppSection) => void;
+/**
+ * Open one account's settings on its outgoing-mail fields.
+ *
+ * The account and the field to land on ride the address, so the banner that
+ * sends the reader there is not also responsible for telling the settings pane
+ * what it was about.
+ */
+export declare function useConfigureAccountSmtp(): (accountId: string) => void;

package/dist/src/routing/sections.js

@@ -0,0 +1,33 @@
+import { useNavigate } from "@tanstack/react-router";
+import { useCallback } from "react";
+const sectionRoute = {
+    brief: "/mail/brief",
+    flagged: "/mail/flagged",
+    outbox: "/mail/outbox",
+    settings: "/settings",
+    accounts: "/settings/accounts",
+    importConfig: "/import",
+};
+/** Go to a top-level section by name, so no caller writes a path. */
+export function useGoToSection() {
+    const navigate = useNavigate();
+    return useCallback((section) => {
+        navigate({ to: sectionRoute[section] });
+    }, [navigate]);
+}
+/**
+ * Open one account's settings on its outgoing-mail fields.
+ *
+ * The account and the field to land on ride the address, so the banner that
+ * sends the reader there is not also responsible for telling the settings pane
+ * what it was about.
+ */
+export function useConfigureAccountSmtp() {
+    const navigate = useNavigate();
+    return useCallback((accountId) => {
+        navigate({
+            to: "/settings/accounts",
+            search: { editAccountId: accountId, focusSmtp: true },
+        });
+    }, [navigate]);
+}