Files
ihasmail-inbuxa/web/src/lib/mailbox/mailboxRoute.ts
T
jcoffey-dev bd6a605d61 Group six more clusters out of web/src/lib
Takes the flat module count from 66 to 42, continuing what admin/ and
calendar/ started.

  lib/mailbox/  archiveDate, emptyFolder, folderMove, labelTree,
                mailboxName, mailboxRoute
  lib/sieve/    sieve, sieveApply, sieveFolders
  lib/input/    keyboard, swipe, touch, listSelection, dropUpload
  lib/notify/   notify, webpush, webpushEnable
  lib/sw/       swCache, swFacts, staleBuild
  lib/text/     html, markdown, text, emlName

FOUR THINGS THE FILENAMES GET WRONG, each checked by reading the file
rather than trusting what it is called:

  - appFolder is not a mailbox. It is the `ihasmail` folder in JMAP
    *Files*, where the client keeps signature images and synced settings.
    It stays flat.
  - format holds no formatting of text. It re-exports the date and clock
    formatters, so it belongs with dates/datetime, not with text/.
  - preview is the file viewer deciding what it can show without
    downloading, and source is where to point someone asking for this
    instance's AGPL source. Neither is about text.
  - notify is not Web Push. It is the tab title, the favicon badge and
    the new-mail sound -- in-app notification, which is why it sits with
    webpush rather than under sw/ with the service worker's own concerns.

threadScroll stays flat too: it decides where a conversation opens, which
is view state rather than a gesture, and input/ is honest only if
everything in it interprets something the reader did.

No behavior change. Almost every reference was on the @/ alias; eight
relative imports in files that did not move, or that moved away from a
sibling, needed rewriting by hand.
2026-09-15 23:17:50 -07:00

28 lines
1.1 KiB
TypeScript

import type { Id, Mailbox } from "@/jmap/types";
/**
* Whether the folder in the address is one this account does not have.
*
* Rendering it as an empty folder was the bug (#111): "Nothing here. This
* folder is empty" is a claim about a folder that is not there, so a stale link
* read as a folder that had emptied itself rather than one that was gone.
*
* The condition that matters is `loaded`. The folder list arrives after the
* first paint, so for a moment every id is unknown -- including the right one.
* Without that gate this answers true on every cold load and sends the reader
* to their inbox from the folder they asked for, which is a worse bug than the
* one it fixes and would look exactly like a flaky link.
*/
export function isUnknownMailbox(args: {
mailboxId: Id | undefined;
mailboxes: Record<Id, Mailbox>;
loaded: boolean;
search?: boolean;
}): boolean {
const { mailboxId, mailboxes, loaded, search } = args;
if (search) return false;
if (!mailboxId) return false;
if (!loaded) return false;
return !mailboxes[mailboxId];
}