npm - @visns-studio/visns-components - Versions diffs - 6.32.3 → 6.34.0 - Mend

@visns-studio/visns-components 6.32.3 → 6.34.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (41) hide show

package/README.md +470 -0
package/package.json +1 -1
package/src/components/DataGrid.jsx +44 -2
package/src/components/Field.jsx +32 -0
package/src/components/Form.jsx +39 -2
package/src/components/Navigation.jsx +274 -15
package/src/components/Notification.jsx +13 -2
package/src/components/TableFilter.jsx +14 -2
package/src/components/auth/Login.jsx +9 -2
package/src/components/auth/PasskeyEnrolPrompt.jsx +269 -0
package/src/components/auth/Profile.jsx +422 -26
package/src/components/auth/authEndpoints.js +43 -0
package/src/components/auth/passkeyClient.js +102 -0
package/src/components/auth/passkeyPrompt.js +408 -0
package/src/components/auth/profileLayout.js +45 -0
package/src/components/controls/DataGridSearch.jsx +16 -2
package/src/components/controls/DataGridSortSheet.jsx +2 -0
package/src/components/generic/ActionButtons.jsx +1 -1
package/src/components/generic/GenericAuth.jsx +197 -21
package/src/components/generic/GenericDetail.jsx +95 -3
package/src/components/generic/GenericMain.jsx +7 -0
package/src/components/generic/StandardModal.jsx +71 -158
package/src/components/sms/SmsCampaigns.jsx +2487 -0
package/src/components/sms/SmsInbox.jsx +18 -0
package/src/components/sms/SmsThreadPanel.jsx +20 -0
package/src/components/sms/smsEndpoints.js +23 -0
package/src/components/styles/DataGrid.module.scss +22 -0
package/src/components/styles/Form.module.scss +100 -2
package/src/components/styles/Navigation.module.scss +322 -5
package/src/components/styles/Notification.module.scss +140 -8
package/src/components/styles/PasskeyEnrolPrompt.module.scss +105 -0
package/src/components/styles/Profile.module.scss +157 -0
package/src/components/styles/Sms.module.scss +451 -0
package/src/components/styles/StandardModal.module.scss +273 -0
package/src/components/styles/global.css +24 -5
package/src/components/utils/navCollapsed.js +201 -0
package/src/components/utils/rowActionSettings.js +76 -0
package/src/components/utils/usePasskeysEnabled.js +84 -0
package/src/components/utils/useShellLayout.js +131 -0
package/src/index.js +103 -1
package/src/utils/rememberTab.js +70 -0

package/src/components/styles/StandardModal.module.scss ADDED Viewed

@@ -0,0 +1,273 @@
+/* ============================================================================
+   StandardModal — the overlay and the panel
+   ----------------------------------------------------------------------------
+   Every measurement here used to be a JavaScript object built per render from
+   `window.innerWidth` and a user-agent sniff, which is why this file is new:
+     - THE SNIFF WAS WRONG for the most common phone-shaped viewport there is.
+       `isMobile` required `isMobileUA || (width <= 768 && hasTouch)`, so a
+       390px window with no touch — a responsive-mode browser, a narrow window
+       on a laptop, a webview that does not advertise touch — was "desktop" and
+       got `min-width: 600px` inside a 390px viewport. That is the horizontal
+       scrollbar under a dialog.
+     - INLINE STYLES CANNOT EXPRESS A FALLBACK, and the one that matters on a
+       phone is `100dvh` with `100vh` behind it. A sheet at `height: 100vh` on
+       iOS Safari is taller than the visual viewport by the height of the
+       browser chrome, so the bottom of the panel — where the Save bar lives —
+       is underneath it. In CSS the two declarations sit one after the other
+       and the engine picks the one it understands.
+     - MEDIA QUERIES APPLY AT THE FIRST PAINT. State initialised from
+       `window.innerWidth` and corrected by a resize listener cannot, which is
+       a frame of desktop-width dialog on the way in.
+   `customStyles.modal` / `customStyles.overlay` are still inline at the call
+   site and therefore still win over everything here, which is what the SMS
+   composer and the gallery rely on.
+   ----------------------------------------------------------------------------
+   THE Z-INDEX ORDER, stated once because three separate stacking decisions
+   have to agree and none of them can see the others:
+     995   the content header (sticky)          Navigation.module.scss
+     996   the rail's pinned account actions    Navigation.module.scss
+    1050   the sidebar rail itself              Navigation.module.scss
+    1200   THIS OVERLAY            --modal-z    here
+    1300   date pickers, incl. the portal   --datepicker-z   global.css
+    9999+  react-select menus portalled to      MultiSelect.jsx,
+           document.body                        ColumnRenderers.jsx
+   The overlay was 1000 — BELOW the 1050 rail, so on a sidebar layout the rail
+   painted over the dialog's left edge and stayed clickable through it. It is
+   1200 now: above every piece of app chrome, and below everything a dialog can
+   itself open, which is the other half of the rule. Both of the things a form
+   opens — a date picker and a portalled select menu — render into `<body>`,
+   outside this overlay's stacking context, so each needs a number ABOVE it or
+   it opens behind the form it belongs to. The date pickers were 1060, chosen
+   years ago to clear "Bootstrap modals (1050)"; moving this overlay to 1200
+   moved them to 1300 in the same change.
+   ========================================================================= */
+.overlay {
+    position: fixed;
+    inset: 0;
+    display: flex;
+    z-index: var(--modal-z, 1200);
+    /* A scroll inside the panel that reaches its end must not continue into
+       the page behind it — the iOS behaviour where the dialog stops moving and
+       the list underneath starts. */
+    overscroll-behavior: contain;
+}
+/* --- the centred dialog --------------------------------------------------- */
+.overlay--modal {
+    align-items: center;
+    justify-content: center;
+    padding: 20px;
+    background-color: rgba(0, 0, 0, 0.5);
+}
+.overlay--top {
+    align-items: flex-start;
+    padding-top: 5%;
+}
+/* --- the side sheet ------------------------------------------------------- */
+.overlay--sheet {
+    align-items: stretch;
+    justify-content: flex-end;
+    padding: 0;
+    /* Was a flat 50% black. A scrim that heavy on a sheet buries the list the
+       sheet exists to keep visible, so the sheet dims less. */
+    background-color: rgba(15, 23, 32, 0.32);
+}
+/* ============================================================================
+   The panel
+   ----------------------------------------------------------------------------
+   ONE SCROLLER, and it is this element. The panel used to scroll AND
+   `.modal__content` inside it used to scroll, both capped at 85vh — so the
+   form's sticky Save bar stuck to the bottom of the inner box, which began
+   below the header and therefore ended below the bottom of the outer one. The
+   only way to reach Save on a long form was to scroll the inner region to its
+   end and then scroll the outer one as well. On a phone, where the sheet was
+   also `100vh` against a shorter visual viewport, it was simply not reachable.
+   `.modal__content` gives its scroll up (see Form.module.scss) and the header
+   and the button bar are sticky inside this one, so both stay on screen at
+   every height.
+   ========================================================================= */
+.panel {
+    position: relative;
+    box-sizing: border-box;
+    background-color: #fff;
+    overflow-y: auto;
+    overscroll-behavior: contain;
+    /* Momentum scrolling, and the thing that stops a touch drag that starts on
+       a label from panning the page instead of the panel. */
+    -webkit-overflow-scrolling: touch;
+}
+.panel--modal {
+    border-radius: 8px;
+    box-shadow: 0 10px 30px rgba(0, 0, 0, 0.3);
+    max-height: 90vh;
+    max-height: 90dvh;
+}
+.panel--small {
+    width: 400px;
+    min-width: 400px;
+    max-width: 600px;
+}
+.panel--medium {
+    width: 80vw;
+    min-width: 600px;
+    max-width: 1200px;
+}
+.panel--large {
+    width: 95vw;
+    min-width: 800px;
+    max-width: 1600px;
+}
+/* --- the sheet ------------------------------------------------------------ */
+.panel--sheet {
+    display: flex;
+    flex-direction: column;
+    max-width: 100vw;
+    height: 100vh;
+    height: 100dvh;
+    border-radius: 0;
+    box-shadow: -12px 0 40px -12px rgba(0, 0, 0, 0.28);
+    /* Honours prefers-reduced-motion through the keyframes the component
+       injects; the transform is the entry, and it is deliberately short. */
+    animation: visnsSheetIn 180ms cubic-bezier(0.32, 0.72, 0, 1);
+}
+/* A sheet's width is FIXED, not a share of the window: a form wants one
+   comfortable measure, and `80vw` gave it a different one on every monitor. */
+.panel--sheet.panel--small {
+    width: min(420px, 96vw);
+    min-width: 0;
+    max-width: 100vw;
+}
+.panel--sheet.panel--medium {
+    width: min(560px, 96vw);
+    min-width: 0;
+    max-width: 100vw;
+}
+.panel--sheet.panel--large {
+    width: min(800px, 96vw);
+    min-width: 0;
+    max-width: 100vw;
+}
+/* ============================================================================
+   Tablet — 641px to 1024px
+   ==========================================================================*/
+@media (max-width: 1024px) {
+    .panel--modal {
+        max-height: 85vh;
+        max-height: 85dvh;
+    }
+    /* THE MINIMUMS COME OFF HERE, not at the phone breakpoint.
+       `.panel--large` is `min-width: 800px` and the overlay spends 20px a
+       side, so a `large` dialog needed 840px of glass — it overflowed every
+       window between 641 and 840px, which is a portrait tablet and a
+       half-screen browser on a laptop. The old code papered over part of that
+       band with a touch sniff and left the rest of it broken. A width cap is
+       all that is wanted: the dialog takes what there is, and a `small`
+       confirm still refuses to stretch across an iPad. */
+    .panel--small,
+    .panel--medium,
+    .panel--large {
+        min-width: 0;
+        max-width: 100%;
+    }
+    .panel--small {
+        width: min(400px, 100%);
+    }
+    .panel--medium {
+        width: min(80vw, 100%);
+    }
+    .panel--large {
+        width: 100%;
+    }
+}
+/* ============================================================================
+   Phone — 640px and below
+   ----------------------------------------------------------------------------
+   Every variant becomes the same thing: a panel that owns the glass. A centred
+   dialog on a phone is a 95vw box with a 20px scrim around it and a shadow
+   nobody can see, and at `min-width: 600px` it was not even that — it was a
+   box wider than the screen with the page scrolling sideways under it.
+   The centred variant lands as a BOTTOM SHEET: full width, pinned to the
+   bottom edge, rounded at the top only. That is where a thumb is, and it is
+   the shape every phone OS uses for exactly this.
+   ==========================================================================*/
+@media (max-width: 640px) {
+    .overlay--modal,
+    .overlay--top {
+        align-items: flex-end;
+        justify-content: stretch;
+        padding: 0;
+    }
+    .panel--modal,
+    .panel--small,
+    .panel--medium,
+    .panel--large {
+        width: 100%;
+        min-width: 0;
+        max-width: 100vw;
+        border-radius: 12px 12px 0 0;
+        box-shadow: 0 -8px 32px rgba(0, 0, 0, 0.28);
+        /* Room for the OS chrome at the top; the rest of the glass is the
+           dialog's. `dvh` is the whole point of the pair — `vh` on iOS Safari
+           measures the viewport as if the address bar were hidden. */
+        max-height: 92vh;
+        max-height: 92dvh;
+    }
+    .panel--sheet {
+        width: 100%;
+        min-width: 0;
+        max-width: 100vw;
+        border-radius: 0;
+        /* A sheet arrives from the right on a desktop. On a phone it IS the
+           screen, so it has no edge to arrive from. */
+        animation: none;
+    }
+    /* Nothing sits under a full-width panel to be seen, and the scrim costs a
+       repaint on every scroll frame on a phone GPU. */
+    .overlay--sheet {
+        background-color: rgba(15, 23, 32, 0.45);
+    }
+}
+/* The safe area under a bottom sheet — the home indicator on a modern iPhone
+   overlaps the last 34px of the glass, which on a bottom-anchored panel is the
+   Save button. */
+@supports (padding: env(safe-area-inset-bottom)) {
+    @media (max-width: 640px) {
+        .panel--modal,
+        .panel--sheet {
+            padding-bottom: env(safe-area-inset-bottom, 0px);
+        }
+    }
+}

package/src/components/styles/global.css CHANGED Viewed

@@ -531,9 +531,17 @@ input[type='time']:not(.visns-native-date-filter__input) {
     z-index: 999 !important;
 }
-/* DatePicker proper z-index hierarchy */
+/* DatePicker proper z-index hierarchy.
+   1060 was chosen to clear "Bootstrap modals (1050)", and it cleared this
+   library's own dialog too for as long as that dialog was 1000. The dialog is
+   1200 now (it has to clear the 1050 sidebar rail — see the ladder at the top
+   of StandardModal.module.scss), so 1060 would open every date picker BEHIND
+   the form it was opened from. `--datepicker-z` keeps the two ends adjustable
+   together; the default sits above the dialog and below the react-select menus
+   portalled to document.body at 9999. */
 .react-datepicker-popper {
-    z-index: 1060 !important; /* Above Bootstrap modals (1050) */
+    z-index: var(--datepicker-z, 1300) !important;
     position: absolute !important; /* Use absolute positioning for proper context */
 }
@@ -543,13 +551,24 @@ input[type='time']:not(.visns-native-date-filter__input) {
     top: 50% !important;
     left: 50% !important;
     transform: translate(-50%, -50%) !important;
-    z-index: 1060 !important;
+    z-index: var(--datepicker-z, 1300) !important;
 }
 /* Portal mode for modal contexts */
 .react-datepicker-popper.portal-mode {
     position: fixed !important;
-    z-index: 1060 !important;
+    z-index: var(--datepicker-z, 1300) !important;
+}
+/* The host DatePickerPortal appends to <body>. It had no rule at all, so it
+   was a `z-index: auto` box at the end of the document — which loses to the
+   dialog's 1200 however late it comes in the DOM, because a positioned
+   ancestor with a real z-index wins over an auto one regardless of order. The
+   popper inside it carries its own z-index, but only once this container
+   stops being the thing that flattens it. */
+.datepicker-portal-container {
+    position: relative;
+    z-index: var(--datepicker-z, 1300);
 }
 .react-datepicker {
@@ -562,7 +581,7 @@ input[type='time']:not(.visns-native-date-filter__input) {
 }
 .react-datepicker-portal {
-    z-index: 1060 !important;
+    z-index: var(--datepicker-z, 1300) !important;
 }
 /* Fix for specific modal header that's causing issues */

package/src/components/utils/navCollapsed.js ADDED Viewed

@@ -0,0 +1,201 @@
+import { useSyncExternalStore } from 'react';
+/**
+ * WHETHER THE SIDEBAR RAIL IS COLLAPSED, and where that fact lives.
+ *
+ * The rail costs 216px of every page, permanently, to show six words. On a
+ * laptop beside a datagrid that is a column of the table; the person who reads
+ * the table all day wants the room back, and the person who navigates all day
+ * does not. So it collapses to an icon strip, and — because it is a preference
+ * about this browser rather than about this account — it is remembered in
+ * `localStorage` and nowhere else. Nothing is sent to a server, so nothing has
+ * to be migrated, permissioned or synced.
+ *
+ * THREE PLACES HOLD IT, in this order of authority:
+ *
+ *   1. `localStorage['visns.nav.collapsed']` — what this browser last chose.
+ *      Read synchronously, in a lazy `useState` initialiser, so the FIRST
+ *      render already has the right width. Read it in an effect instead and
+ *      the rail paints wide and snaps narrow, which is the one thing a
+ *      persisted layout preference must not do.
+ *   2. `<html data-nav-collapsed="true">` — the live state, written by
+ *      Navigation. This is what CSS keys off (the rail's own rules, and a
+ *      consuming app's if it wants to react), and what `useNavCollapsed`
+ *      subscribes to.
+ *   3. React state inside Navigation, which drives 2.
+ *
+ * ABSENT MEANS EXPANDED, everywhere: no storage, no attribute, no document,
+ * unreadable storage, a value that is not 'true' or 'false'. Expanded is what
+ * every existing app renders today, so every way this can fail lands on the
+ * rendering that is already deployed.
+ */
+/** The attribute Navigation writes on `<html>`. */
+export const NAV_COLLAPSED_ATTRIBUTE = 'data-nav-collapsed';
+/** The localStorage key the preference is remembered under. */
+export const NAV_COLLAPSED_STORAGE_KEY = 'visns.nav.collapsed';
+/**
+ * Only ever 'true' or 'false' is written, and only 'true' is read as
+ * collapsed — so a key some other tool has scribbled on, or a half-written
+ * value from a storage quota error, reads as expanded rather than as a
+ * mystery.
+ */
+const parseCollapsed = (raw) => raw === 'true';
+/**
+ * `localStorage`, when there is one that can be touched.
+ *
+ * Private-mode Safari throws on ACCESS, not just on write, and an embedded
+ * webview can have the property missing altogether — so even reading the
+ * global is inside the try.
+ *
+ * @returns {Storage|null}
+ */
+const storage = () => {
+    try {
+        if (typeof window === 'undefined' || !window.localStorage) {
+            return null;
+        }
+        return window.localStorage;
+    } catch (unavailable) {
+        return null;
+    }
+};
+/**
+ * The remembered preference, straight from storage.
+ *
+ * This is the one to use as a `useState` initialiser: it does not depend on
+ * the attribute having been written yet, which on the first render it has not.
+ *
+ * @returns {boolean}
+ */
+export const getStoredNavCollapsed = () => {
+    const store = storage();
+    if (!store) {
+        return false;
+    }
+    try {
+        return parseCollapsed(store.getItem(NAV_COLLAPSED_STORAGE_KEY));
+    } catch (unreadable) {
+        return false;
+    }
+};
+/**
+ * Remember the preference. Failing to write is not an error worth surfacing —
+ * the rail still collapses, it just forgets by the next page load.
+ *
+ * @param {boolean} collapsed
+ */
+export const storeNavCollapsed = (collapsed) => {
+    const store = storage();
+    if (!store) {
+        return;
+    }
+    try {
+        store.setItem(NAV_COLLAPSED_STORAGE_KEY, collapsed ? 'true' : 'false');
+    } catch (full) {
+        /* Quota, private mode, a locked-down webview — all the same answer. */
+    }
+};
+/**
+ * Write (or clear) the attribute on `<html>`.
+ *
+ * `false` REMOVES the attribute rather than writing `"false"`: an app that has
+ * never collapsed its rail should have nothing on its root element, the same
+ * way `data-density` is absent at the default density.
+ *
+ * @param {boolean} collapsed
+ */
+export const applyNavCollapsed = (collapsed) => {
+    if (typeof document === 'undefined' || !document.documentElement) {
+        return;
+    }
+    if (collapsed) {
+        document.documentElement.setAttribute(NAV_COLLAPSED_ATTRIBUTE, 'true');
+    } else {
+        document.documentElement.removeAttribute(NAV_COLLAPSED_ATTRIBUTE);
+    }
+};
+/**
+ * The live state, read off `<html>`.
+ *
+ * Falls back to the stored preference while the attribute is absent, so a
+ * component that renders before Navigation's insertion effect has run — one
+ * mounted outside the shell, or the very first render of the page — sizes
+ * itself to the rail the user is about to see rather than to the one they
+ * are not.
+ *
+ * @returns {boolean}
+ */
+export const getNavCollapsed = () => {
+    if (typeof document === 'undefined' || !document.documentElement) {
+        return false;
+    }
+    if (!document.documentElement.hasAttribute(NAV_COLLAPSED_ATTRIBUTE)) {
+        return getStoredNavCollapsed();
+    }
+    return parseCollapsed(
+        document.documentElement.getAttribute(NAV_COLLAPSED_ATTRIBUTE)
+    );
+};
+/**
+ * Collapse or expand the rail from outside Navigation — a keyboard shortcut in
+ * a consuming app, a "focus mode" button on a report page.
+ *
+ * Writes both places at once. Navigation's own effect keys off the attribute's
+ * MutationObserver like everybody else, so its toggle button and its rows stay
+ * in step without a shared React context.
+ *
+ * @param {boolean} collapsed
+ */
+export const setNavCollapsed = (collapsed) => {
+    const next = Boolean(collapsed);
+    storeNavCollapsed(next);
+    applyNavCollapsed(next);
+};
+/** Notify on the attribute changing. Same shape as `useShellLayout`'s. */
+const subscribeToNavCollapsed = (onChange) => {
+    if (
+        typeof document === 'undefined' ||
+        typeof MutationObserver === 'undefined' ||
+        !document.documentElement
+    ) {
+        return () => {};
+    }
+    const observer = new MutationObserver(onChange);
+    observer.observe(document.documentElement, {
+        attributes: true,
+        attributeFilter: [NAV_COLLAPSED_ATTRIBUTE],
+    });
+    return () => observer.disconnect();
+};
+/**
+ * Whether the rail is collapsed, as a subscription.
+ *
+ * @returns {boolean}
+ */
+export const useNavCollapsed = () =>
+    useSyncExternalStore(subscribeToNavCollapsed, getNavCollapsed, () => false);
+export default useNavCollapsed;

package/src/components/utils/rowActionSettings.js CHANGED Viewed

@@ -115,3 +115,79 @@ export const filterPickerOptions = (options, search) => {
         String(option.label).toLowerCase().includes(term)
     );
 };
+/**
+ * IS THIS ROW ACTION DISABLED, AND WHY?
+ *
+ * A settings entry could already be taken away per row with
+ * `condition: (row) => boolean` — the icon is simply not rendered. That is the
+ * right answer when the action does not apply to the row at all, and the wrong
+ * one when it applies but is not permitted: an icon that is present on nine
+ * rows and absent on the tenth reads as a rendering bug, and it answers none of
+ * the question the user actually has, which is "why not this one".
+ *
+ * `disabled: (row) => boolean | string` keeps the icon in the row and makes it
+ * inert. Returning a STRING both disables the action and says why, and the
+ * string replaces the action's ordinary tooltip — which is the only place the
+ * reason can go, since the cell is one 18px glyph:
+ *
+ *   {
+ *     id: 'update',
+ *     disabled: (row) =>
+ *       row.name === 'Administrator'
+ *         ? 'The Administrator role cannot be changed.'
+ *         : false,
+ *   }
+ *
+ * `condition` and `disabled` are independent and may both be set; `condition`
+ * still hides, and a hidden action is never asked whether it is disabled.
+ *
+ * A THROWING PREDICATE IS NOT DISABLED. This is deliberately the opposite of
+ * `condition`, which hides on a throw: there, failing closed costs a verb the
+ * user might not have been allowed anyway; here, failing closed would disable a
+ * legitimate action across every row of the grid on one bad field access, with
+ * a tooltip that cannot explain itself. Failing open leaves the action exactly
+ * as it was before the predicate existed.
+ *
+ * A literal is accepted as well as a function, because `disabled: true` on a
+ * whole settings entry is a reasonable thing to write and there is no reason to
+ * make a host wrap it in an arrow.
+ *
+ * @param {object} setting  A root `settings` entry.
+ * @param {object} row      The row the action would act on.
+ * @returns {{disabled: boolean, reason: string}} `reason` is '' unless the
+ *   predicate returned a non-empty string.
+ */
+export const resolveRowActionDisabled = (setting, row) => {
+    const NOT_DISABLED = { disabled: false, reason: '' };
+    const rule = setting?.disabled;
+    if (rule === undefined || rule === null || rule === false) {
+        return NOT_DISABLED;
+    }
+    if (typeof rule !== 'function') {
+        return asDisabledResult(rule);
+    }
+    try {
+        return asDisabledResult(rule(row));
+    } catch (error) {
+        return NOT_DISABLED;
+    }
+};
+/** One shape for a predicate's answer, whatever it returned. */
+const asDisabledResult = (value) => {
+    if (typeof value === 'string') {
+        // An empty string is not a reason, and it is not a yes either — it is
+        // what a host's `row.locked_reason` returns when the row is not locked.
+        return value.trim()
+            ? { disabled: true, reason: value }
+            : { disabled: false, reason: '' };
+    }
+    return value
+        ? { disabled: true, reason: '' }
+        : { disabled: false, reason: '' };
+};

package/src/components/utils/usePasskeysEnabled.js ADDED Viewed

@@ -0,0 +1,84 @@
+import { useSyncExternalStore } from 'react';
+/**
+ * WHETHER THIS APPLICATION OFFERS PASSKEYS, readable from anywhere.
+ *
+ * Exactly the arrangement `data-layout` uses (utils/useShellLayout.js), for
+ * exactly the same reason. `GenericAuth` takes the `passkeys` prop and can
+ * hand it to the screens it mounts itself — the login screen, the enrolment
+ * prompt — but the profile screen is NOT one of those: it is mounted by the
+ * consuming app's own `routeConfig`, several components below the route table,
+ * and the only props it is given are `userProfile` and `setUserProfile` (see
+ * GenericMain's `renderRoutes`).
+ *
+ * So the switch mirrors itself onto `<html>` as `data-passkeys="on"`, written
+ * once by GenericAuth, and the profile screen reads it. The alternative was to
+ * make every consuming app pass `passkeys` a second time when it builds its
+ * route config, which is a step every app would have to be edited for and
+ * would silently be skipped by the ones that were not.
+ *
+ * ABSENT MEANS OFF, which is what every app that never passed the prop gets.
+ */
+/** The attribute GenericAuth writes on `<html>`. */
+export const PASSKEYS_ATTRIBUTE = 'data-passkeys';
+/** The value it is written with. */
+export const PASSKEYS_ENABLED_VALUE = 'on';
+/**
+ * Is the attribute set, right now?
+ *
+ * SSR-safe: no document means off — the same answer the first client render
+ * produces before GenericAuth's insertion effect has run, so the markup
+ * matches on hydration.
+ *
+ * @returns {boolean}
+ */
+export const getPasskeysEnabled = () => {
+    if (typeof document === 'undefined' || !document.documentElement) {
+        return false;
+    }
+    return (
+        document.documentElement.getAttribute(PASSKEYS_ATTRIBUTE) ===
+        PASSKEYS_ENABLED_VALUE
+    );
+};
+/**
+ * Notify on the attribute changing.
+ *
+ * It changes once per page in a normal app, but that once can land AFTER the
+ * first render of a screen mounted in the same commit — a refresh straight
+ * onto `/profile` is the ordinary case — and a screen that read `false` then
+ * and never heard again would hide the tab for the life of the page.
+ */
+const subscribe = (onChange) => {
+    if (
+        typeof document === 'undefined' ||
+        typeof MutationObserver === 'undefined' ||
+        !document.documentElement
+    ) {
+        return () => {};
+    }
+    const observer = new MutationObserver(onChange);
+    observer.observe(document.documentElement, {
+        attributes: true,
+        attributeFilter: [PASSKEYS_ATTRIBUTE],
+    });
+    return () => observer.disconnect();
+};
+/**
+ * Whether passkeys are on, as a subscription.
+ *
+ * @returns {boolean}
+ */
+export const usePasskeysEnabled = () =>
+    useSyncExternalStore(subscribe, getPasskeysEnabled, () => false);
+export default usePasskeysEnabled;