@jbrowse/display-ui 5.0.0-beta.11 → 5.0.0-beta.14

package/esm/YScaleBar.js

@@ -2,18 +2,11 @@ import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
 import { usePalette } from '@jbrowse/core/ui/PaletteContext';
 import { AXIS_FONT_PX, TICK_LABEL_X_PX } from './yAxisConstants.js';
 import { clampStrokeInsideAxis } from './yScaleTicks.js';
-// Not an `observer`, and deliberately: there is nothing here to observe. Every
-// caller already reads `model.ticks` inside its own observer and hands the
-// resolved plain object down, and `usePalette` is a React context, not MobX.
-// Wrapping it anyway allocated a Reaction per instance — multi-wiggle renders
-// one per sample row, on screen as well as in export — and, per CLAUDE.md, put
-// the component out of `babel-plugin-react-compiler`'s reach, so it got neither
-// the MobX tracking it doesn't need nor the memoization it does. Its sibling
-// `CrossHatchLines`, consuming the same ticks, is already plain.
 // Half the vertical space a 10px label needs, halo included: digits reach about
 // 3.6px above the centered baseline and the 2.5px-wide background stroke another
 // 1.25px past that.
 const LABEL_HALF_HEIGHT_PX = 5;
+// eslint-disable-next-line no-restricted-syntax -- drawn inside a frozen SVG figure
 export default function YScaleBar({ ticks, orientation, bandHeight, }) {
     const palette = usePalette();
     if (!ticks) {

package/esm/YScaleBarOverlay.d.ts

@@ -4,8 +4,9 @@ import type { YAxis } from './valueScale.ts';
  * positioned absolutely over the band at `top`, with `AxisGutter` inside. A
  * right-side gutter clears the vertical scrollbar a display may mount.
  */
-export default function YScaleBarOverlay({ axis, top, width, }: {
+declare const YScaleBarOverlay: ({ axis, top, width, }: {
     axis: YAxis;
     top: number;
     width: number;
-}): import("react").JSX.Element;
+}) => import("react").JSX.Element;
+export default YScaleBarOverlay;

package/esm/YScaleBarOverlay.js

@@ -1,5 +1,6 @@
 import { jsx as _jsx } from "react/jsx-runtime";
 import { VERTICAL_SCROLLBAR_CLEARANCE } from '@jbrowse/core/ui/VerticalScrollbar';
+import { observer } from 'mobx-react';
 import AxisGutter from './AxisGutter.js';
 import { axisGutterLeft, axisGutterWidth } from './axisPlacement.js';
 /**
@@ -7,7 +8,7 @@ import { axisGutterLeft, axisGutterWidth } from './axisPlacement.js';
  * positioned absolutely over the band at `top`, with `AxisGutter` inside. A
  * right-side gutter clears the vertical scrollbar a display may mount.
  */
-export default function YScaleBarOverlay({ axis, top, width, }) {
+const YScaleBarOverlay = observer(function YScaleBarOverlay({ axis, top, width, }) {
     return (_jsx("svg", { style: {
             position: 'absolute',
             top,
@@ -17,4 +18,5 @@ export default function YScaleBarOverlay({ axis, top, width, }) {
             width: axisGutterWidth(axis),
             overflow: 'visible',
         }, children: _jsx(AxisGutter, { axis: axis }) }));
-}
+});
+export default YScaleBarOverlay;

package/esm/axisPlacement.d.ts

@@ -8,7 +8,7 @@ import type { ValueScale, YAxis } from './valueScale.ts';
 export declare const COMPACT_AXIS_HEIGHT = 30;
 /**
  * Whether a scale places anything by y, which is whether its rules draw: it
- * rules at least one band, where `[]` is a scale mapped to colour instead.
+ * rules at least one band, where `[]` is a scale mapped to color instead.
  */
 export declare function rulesABand(scale: Pick<ValueScale, 'bandTops'>): boolean;
 /**
@@ -30,11 +30,19 @@ export declare function axisCaptionY(axis: Pick<YAxis, 'ticks'>, bandTops: numbe
  */
 export declare function axisGutterWidth(axis: Pick<YAxis, 'ticks' | 'caption'>): number;
 /**
- * Px the export's left margin holds for these axes: the widest left-side axis
- * that draws, 0 when none does. A sidebar the export parks left of the figure
- * sits past this strip so the scalebars stay beside the plot.
+ * Px the export's left margin holds for these axes, 0 when no left-side axis
+ * draws. `axisGutterLeft` puts every left axis's outer edge this far out, a
+ * wider gutter growing inward over the plot, so a sidebar the export parks left
+ * of the figure sits past this strip.
  */
-export declare function leftAxisGutterWidth(axes: readonly Pick<YAxis, 'side' | 'ticks' | 'caption' | 'height' | 'bandTops'>[]): number;
+export declare function leftAxisGutterWidth(axes: readonly Pick<YAxis, 'side' | 'height' | 'bandTops'>[]): 0 | 50;
+/**
+ * Whether an axis's numbers grow rightward from its spine: a right-side axis
+ * keeps them inside the plot's right edge, and a left-side axis set past a
+ * panel keeps its spine against the panel. Only a left-side axis at the
+ * display's own edge grows them leftward, toward that edge.
+ */
+export declare function numbersGrowRight(axis: Pick<YAxis, 'side' | 'left'>): boolean;
 /** How far in from the plot's right edge a right-side gutter ends in an export. */
 export declare const AXIS_RIGHT_INSET_PX = 4;
 /**
@@ -42,9 +50,8 @@ export declare const AXIS_RIGHT_INSET_PX = 4;
  * gutter inside the plot's right edge, less `rightInset` (the vertical
  * scrollbar a display may mount on screen; a margin in an export). A left-side
  * axis takes the gutter at the display's left edge, past whatever panel the
- * scale's `left` reserves — except in an export, whose margin is the gutter,
- * so an axis nothing pushes right sits in the margin with its numbers outside
- * the plot and its spine on the content edge, or past it by what
- * `axisGutterWidth` grew.
+ * scale's `left` reserves — except in an export, whose margin is the gutter:
+ * the export parks that panel left of the margin, so the axis sits between
+ * the two with its numbers outside the plot.
  */
 export declare function axisGutterLeft(axis: Pick<YAxis, 'side' | 'left' | 'ticks' | 'caption'>, width: number, rightInset: number, exportContentLeft?: number): number;

package/esm/axisPlacement.js

@@ -10,7 +10,7 @@ import { AXIS_GUTTER_WIDTH_PX } from './yScaleTicks.js';
 export const COMPACT_AXIS_HEIGHT = 30;
 /**
  * Whether a scale places anything by y, which is whether its rules draw: it
- * rules at least one band, where `[]` is a scale mapped to colour instead.
+ * rules at least one band, where `[]` is a scale mapped to color instead.
  */
 export function rulesABand(scale) {
     return (scale.bandTops?.length ?? 1) > 0;
@@ -48,14 +48,24 @@ export function axisGutterWidth(axis) {
     return Math.max(AXIS_GUTTER_WIDTH_PX, Math.ceil(CAPTION_BAND_PX + widest + TICK_LABEL_X_PX));
 }
 /**
- * Px the export's left margin holds for these axes: the widest left-side axis
- * that draws, 0 when none does. A sidebar the export parks left of the figure
- * sits past this strip so the scalebars stay beside the plot.
+ * Px the export's left margin holds for these axes, 0 when no left-side axis
+ * draws. `axisGutterLeft` puts every left axis's outer edge this far out, a
+ * wider gutter growing inward over the plot, so a sidebar the export parks left
+ * of the figure sits past this strip.
  */
 export function leftAxisGutterWidth(axes) {
-    return Math.max(0, ...axes
-        .filter(axis => axis.side !== 'right' && axisDrawn(axis))
-        .map(axisGutterWidth));
+    return axes.some(axis => axis.side !== 'right' && axisDrawn(axis))
+        ? AXIS_GUTTER_WIDTH_PX
+        : 0;
+}
+/**
+ * Whether an axis's numbers grow rightward from its spine: a right-side axis
+ * keeps them inside the plot's right edge, and a left-side axis set past a
+ * panel keeps its spine against the panel. Only a left-side axis at the
+ * display's own edge grows them leftward, toward that edge.
+ */
+export function numbersGrowRight(axis) {
+    return axis.side === 'right' || (axis.left ?? 0) > 0;
 }
 /** How far in from the plot's right edge a right-side gutter ends in an export. */
 export const AXIS_RIGHT_INSET_PX = 4;
@@ -64,17 +74,15 @@ export const AXIS_RIGHT_INSET_PX = 4;
  * gutter inside the plot's right edge, less `rightInset` (the vertical
  * scrollbar a display may mount on screen; a margin in an export). A left-side
  * axis takes the gutter at the display's left edge, past whatever panel the
- * scale's `left` reserves — except in an export, whose margin is the gutter,
- * so an axis nothing pushes right sits in the margin with its numbers outside
- * the plot and its spine on the content edge, or past it by what
- * `axisGutterWidth` grew.
+ * scale's `left` reserves — except in an export, whose margin is the gutter:
+ * the export parks that panel left of the margin, so the axis sits between
+ * the two with its numbers outside the plot.
  */
 export function axisGutterLeft(axis, width, rightInset, exportContentLeft) {
     if (axis.side === 'right') {
         return width - rightInset - axisGutterWidth(axis);
     }
-    const left = axis.left ?? 0;
-    return exportContentLeft !== undefined && left === 0
+    return exportContentLeft !== undefined
         ? exportContentLeft - AXIS_GUTTER_WIDTH_PX
-        : left;
+        : (axis.left ?? 0);
 }

package/esm/bottomRightCorner.d.ts

@@ -2,56 +2,28 @@
  * #api
  * The one box per display that owns the bottom-right corner.
  *
- * It lives beside the overlay contract rather than with the chrome that mounts
- * it, because it is the half of that contract the types cannot carry:
- * `DisplayChromeOverlays.BackgroundProgress` is the one state told to render an
- * in-flow chip with no `position` and no corner offsets, and this is the box it
- * is laid out in. A host writing their own display over `DisplayChromeBase`
- * needs to be able to build that corner; while this sat one layer up in the LGV
- * plugin, the rule was a paragraph they could only obey by hand.
+ * Two members share it: the display's own control row
+ * (`BottomRightIndicators`) and the chrome's background-progress chip
+ * (`DisplayChromeOverlays.BackgroundProgress`). Both portal into the same
+ * per-track overlay node, so each claiming the corner with its own
+ * `position: absolute` box draws one over the other. The chrome renders this
+ * box, lays its chip out in it, and publishes the node here so the control row,
+ * rendered inside the chrome's body, lands in the same flex column.
  *
- * Two independent things want that corner and neither could see the other:
- * the display's own control row (`BottomRightIndicators` — track sizing, the
- * isoform notice, the solo chip) and the chrome's background-progress chip
- * (`DisplayChromeOverlays.BackgroundProgress`, the status channel for work with
- * no fetch behind it). Both portal into the *same* per-track overlay node, and
- * both used to claim `bottom: 2; right: 2` there with their own
- * `position: absolute` box — so they simply drew on top of each other, the
- * controls winning on z-index and the status text disappearing under them.
- *
- * It has never been reachable: the two displays that render the control row
- * (alignments, canvas) are not among the four that report a `ready`-phase
- * status (clustering, on multi-wiggle / multi-row features / maf / the
- * multi-sample variant pair). The layout is structural anyway, because neither
- * side checks for the constraint, so the first display to want both would hit
- * the bug as a status message that never appears.
- *
- * `BottomRightIndicators` already described itself as "the single anchor point
- * for every bottom-right overlay ... so they lay out as one row instead of each
- * picking their own position and colliding". This makes that true of the chip
- * too: the chrome renders the anchor, puts its chip in it, and publishes the
- * node here so the display's row — rendered several components away, inside the
- * chrome's body — lands in the same flex box instead of over it.
- *
- * `null` outside a chrome (a display an embedder mounts standalone, a unit
- * test, the SVG export), where `BottomRightIndicators` keeps its own anchored
- * box. That fallback is why this can be added without every consumer changing.
+ * - A host writing their own display over `DisplayChromeBase` builds the corner
+ *   from this; the chip is told to render in-flow, with no `position` and no
+ *   corner offsets.
+ * - `null` outside a chrome (a standalone mount, a unit test, the SVG export),
+ *   where `BottomRightIndicators` anchors its own box.
  */
 export declare const BottomRightCornerContext: import("react").Context<HTMLElement | null>;
 /**
- * Members are stacked, not laid side by side, and ordered explicitly.
- *
- * Stacked because the status chip is much wider than a control (it carries a
- * label and a 120px bar): in one horizontal row it would shove the controls
- * leftwards whenever a background job started and let them snap back when it
- * finished.
- *
- * Ordered by `order` rather than by DOM position because one member arrives as
- * a portal and the other as an ordinary child, and the relative order of those
- * two inside the container is not something React documents. Only the control
- * row needs a value: the status chip takes CSS's default 0, so anything the
- * chrome adds to the corner later sorts above the controls unless it says
- * otherwise — which is the right default, the controls being the thing whose
- * position in the corner users learn.
+ * The control row's flex `order` in the corner column. The members stack
+ * rather than sit side by side, so a wide status chip starting or finishing
+ * never shoves the controls sideways. `order` sets the sequence because one
+ * member arrives as a portal and the other as a child, and React does not
+ * document their relative DOM order. The chip takes CSS's default 0, so
+ * anything the chrome adds later sorts above the controls, whose position users
+ * learn.
  */
 export declare const BOTTOM_RIGHT_CONTROLS_ORDER = 1;

package/esm/bottomRightCorner.js

@@ -3,56 +3,28 @@ import { createContext } from 'react';
  * #api
  * The one box per display that owns the bottom-right corner.
  *
- * It lives beside the overlay contract rather than with the chrome that mounts
- * it, because it is the half of that contract the types cannot carry:
- * `DisplayChromeOverlays.BackgroundProgress` is the one state told to render an
- * in-flow chip with no `position` and no corner offsets, and this is the box it
- * is laid out in. A host writing their own display over `DisplayChromeBase`
- * needs to be able to build that corner; while this sat one layer up in the LGV
- * plugin, the rule was a paragraph they could only obey by hand.
+ * Two members share it: the display's own control row
+ * (`BottomRightIndicators`) and the chrome's background-progress chip
+ * (`DisplayChromeOverlays.BackgroundProgress`). Both portal into the same
+ * per-track overlay node, so each claiming the corner with its own
+ * `position: absolute` box draws one over the other. The chrome renders this
+ * box, lays its chip out in it, and publishes the node here so the control row,
+ * rendered inside the chrome's body, lands in the same flex column.
  *
- * Two independent things want that corner and neither could see the other:
- * the display's own control row (`BottomRightIndicators` — track sizing, the
- * isoform notice, the solo chip) and the chrome's background-progress chip
- * (`DisplayChromeOverlays.BackgroundProgress`, the status channel for work with
- * no fetch behind it). Both portal into the *same* per-track overlay node, and
- * both used to claim `bottom: 2; right: 2` there with their own
- * `position: absolute` box — so they simply drew on top of each other, the
- * controls winning on z-index and the status text disappearing under them.
- *
- * It has never been reachable: the two displays that render the control row
- * (alignments, canvas) are not among the four that report a `ready`-phase
- * status (clustering, on multi-wiggle / multi-row features / maf / the
- * multi-sample variant pair). The layout is structural anyway, because neither
- * side checks for the constraint, so the first display to want both would hit
- * the bug as a status message that never appears.
- *
- * `BottomRightIndicators` already described itself as "the single anchor point
- * for every bottom-right overlay ... so they lay out as one row instead of each
- * picking their own position and colliding". This makes that true of the chip
- * too: the chrome renders the anchor, puts its chip in it, and publishes the
- * node here so the display's row — rendered several components away, inside the
- * chrome's body — lands in the same flex box instead of over it.
- *
- * `null` outside a chrome (a display an embedder mounts standalone, a unit
- * test, the SVG export), where `BottomRightIndicators` keeps its own anchored
- * box. That fallback is why this can be added without every consumer changing.
+ * - A host writing their own display over `DisplayChromeBase` builds the corner
+ *   from this; the chip is told to render in-flow, with no `position` and no
+ *   corner offsets.
+ * - `null` outside a chrome (a standalone mount, a unit test, the SVG export),
+ *   where `BottomRightIndicators` anchors its own box.
  */
 export const BottomRightCornerContext = createContext(null);
 /**
- * Members are stacked, not laid side by side, and ordered explicitly.
- *
- * Stacked because the status chip is much wider than a control (it carries a
- * label and a 120px bar): in one horizontal row it would shove the controls
- * leftwards whenever a background job started and let them snap back when it
- * finished.
- *
- * Ordered by `order` rather than by DOM position because one member arrives as
- * a portal and the other as an ordinary child, and the relative order of those
- * two inside the container is not something React documents. Only the control
- * row needs a value: the status chip takes CSS's default 0, so anything the
- * chrome adds to the corner later sorts above the controls unless it says
- * otherwise — which is the right default, the controls being the thing whose
- * position in the corner users learn.
+ * The control row's flex `order` in the corner column. The members stack
+ * rather than sit side by side, so a wide status chip starting or finishing
+ * never shoves the controls sideways. `order` sets the sequence because one
+ * member arrives as a portal and the other as a child, and React does not
+ * document their relative DOM order. The chip takes CSS's default 0, so
+ * anything the chrome adds later sorts above the controls, whose position users
+ * learn.
  */
 export const BOTTOM_RIGHT_CONTROLS_ORDER = 1;

package/esm/chromeOverlayContext.js

@@ -1,32 +1,17 @@
 import { createContext, use } from 'react';
-// The context alone, in a module of its own, so that consuming the seam does not
-// import the thing the seam exists to replace.
-//
-// `DisplayChrome.tsx` is where the Material set is bound, and it used to hold
-// this `createContext` too. That put 45 `@mui/*`-importing modules one hop from
-// `DisplayUIProvider` — the component whose whole purpose is "I do not want
-// Material UI in my app" — and the build agreed: the build-your-own site's
-// "Removing Material UI" page carried 34 first-party eager modules importing
-// `@mui/material` against 16 on the page that deliberately leaves the Material
-// chrome on screen, and 53 KB gzip more. Nothing rendered them. A DOM census
-// cannot see a module graph, so nothing said so.
-//
-// The rule that falls out, and it applies to any seam: **the override channel
-// must not live in the module that binds the default.** Everything toolkit-free
-// (`plainChromeOverlays`, `plainTrackControl`, `DisplayChromeBase`,
-// `DisplayUIProvider`) reaches zero `@mui/*` modules, and
-// `muiFreeSeam.test.ts` fails naming the import trail if that stops being true.
+// The context alone, in a module of its own: the override channel must not live
+// in the module that binds the default. `DisplayChrome.tsx` binds the Material
+// set, so a provider imported from there put Material UI in the graph of the
+// apps asking to leave it out. `muiFree.test.ts` fails naming the import trail
+// if a toolkit-free module reaches `@mui/*` again.
 /**
  * Runtime override for the overlay set. **Defaults to undefined, not to a
- * component set**. A plain default would degrade every display that renders
- * outside a provider (unit tests, SVG export, breakpoint-split-view's
- * overlayUtils): the display would still work, but stop looking like JBrowse. Undefined means
- * "nobody asked", so `DisplayChrome` keeps its MUI set and nothing changes.
+ * component set**: undefined means "nobody asked", so a display rendered
+ * outside a provider (unit tests, SVG export) keeps JBrowse's own look.
  *
- * This is the escape hatch for embedders who want JBrowse's *own* displays
- * (wiggle, alignments, variants — all of which import `DisplayChrome` directly
- * and so can't be redirected at the import level) to draw with their overlays:
- * no MUI rendered, no ThemeProvider needed, no emotion in their page.
+ * This is how an embedder makes JBrowse's own displays, which import
+ * `DisplayChrome` directly, draw with their overlays: no MUI rendered, no
+ * ThemeProvider needed, no emotion in their page.
  *
  * Prefer `DisplayUIProvider`, which mounts this and the track-control context
  * together and accepts a partial set. Reach for this one only to override

package/esm/chromeOverlays.d.ts

@@ -1,90 +1,96 @@
 import type { ComponentType } from 'react';
-/** What `ErrorBar` reads: a failed fetch, and the way to run it again. */
-export interface DisplayErrorBarModel {
+/** What `RenderError` draws: a render-backend failure and the re-init. */
+export interface RenderErrorProps {
     error: unknown;
-    reload: () => void;
+    onRetry: () => void;
+    height: number;
 }
-/** What `Loading` reads. Everything is optional — a display that reports no
- * progress and offers no cancel still gets a scrim. */
-export interface DisplayLoadingOverlayModel {
-    statusMessage?: string;
-    statusProgress?: number;
-    fetchCanceled?: boolean;
-    cancelFetchByUser?: () => void;
-    reload?: () => void;
+/**
+ * What `TooLarge` draws: the byte gate's banner text and the way past it.
+ * `onForceLoad` is the whole point of the state; without it the region is
+ * unreachable for the rest of the session.
+ */
+export interface TooLargeProps {
+    message: string;
+    onForceLoad: () => void;
 }
-/** What `BackgroundProgress` reads: the status channel for work with no fetch
- * behind it, while the phase is `ready`. */
-export interface DisplayBackgroundProgressModel {
-    statusMessage?: string;
-    statusProgress?: number;
+/**
+ * What `ErrorBar` draws: a failed fetch. No `onRetry` means a Retry cannot
+ * clear it (the byte gate tripped inside the fetch), so draw the message as
+ * information.
+ */
+export interface ErrorBarProps {
+    error: unknown;
+    onRetry?: () => void;
+}
+/**
+ * What `Loading` draws. A display that reports no progress and offers no cancel
+ * passes neither, and still gets a scrim. `canceled` swaps Cancel for Retry.
+ */
+export interface LoadingProps {
+    visible: boolean;
+    immediate?: boolean;
+    message?: string;
+    progress?: number;
+    canceled?: boolean;
+    onCancel?: () => void;
+    onRetry?: () => void;
 }
-/** What `TooLarge` reads. `forceLoad` is the whole point of the state — see the
- * entry below. */
-export interface TooLargeMessageModel {
-    regionTooLargeReason: string;
-    zoomCanReleaseGate: boolean;
-    forceLoad: () => void;
+/** What `BackgroundProgress` draws: work with no fetch behind it. */
+export interface BackgroundProgressProps {
+    message?: string;
+    progress?: number;
 }
+/**
+ * The five components that draw `displayPhase`'s terminal and overlay states.
+ * `DisplayChromeBase` decides which renders, reads the display model, and hands
+ * each plain values and callbacks, so a set needs no model, no MobX and no UI
+ * toolkit: an embedder with their own design system supplies plain markup and
+ * ships no ThemeProvider. Every import above is type-only, so this module pulls
+ * no runtime dependency.
+ *
+ * A replacement set must render something for each state; four test systems
+ * key on the testids in `plainChromeOverlays.tsx`.
+ *
+ * `ErrorBar`, `Loading` and `BackgroundProgress` are portalled as a group into
+ * the LGV's per-track overlay layer, which is `pointer-events: none`, so
+ * anything of yours the user clicks sets `pointer-events: auto` on its own
+ * positioned box. `BackgroundProgress` alone does not own its box; see its
+ * entry.
+ */
 export interface DisplayChromeOverlays {
     /**
      * GPU/render-backend failure. A subtree-replacing terminal state: the canvas
      * unmounts and the backend disposes, so this owns the full display area.
      */
-    RenderError: ComponentType<{
-        error: unknown;
-        onRetry: () => void;
-        height: number;
-    }>;
-    /**
-     * The byte gate tripped. Also subtree-replacing. Must offer `model.forceLoad`
-     * or the region becomes unreachable for the rest of the session.
-     */
-    TooLarge: ComponentType<{
-        model: TooLargeMessageModel;
-    }>;
+    RenderError: ComponentType<RenderErrorProps>;
+    /** The byte gate tripped. Also subtree-replacing. */
+    TooLarge: ComponentType<TooLargeProps>;
     /**
      * Fetch error, drawn *over* a live canvas rather than replacing it. Mounted
-     * unconditionally like the two below, so `visible` (`displayPhase ===
-     * 'error'`) is the gate -- don't re-derive it from `model.error`, which is
-     * the same subtraction `displayPhase` exists to retire.
+     * only while the phase is `error`.
      */
-    ErrorBar: ComponentType<{
-        model: DisplayErrorBarModel;
-        visible: boolean;
-    }>;
+    ErrorBar: ComponentType<ErrorBarProps>;
     /**
-     * The loading scrim. `visible` is `displayPhase` `loading` or `canceled`,
-     * the second drawn from `model.fetchCanceled` with Retry in place of Cancel;
-     * `immediate` asks it to skip its anti-flash delay because nothing is painted
+     * The loading scrim, `visible` in the `loading` and `canceled` phases;
+     * `immediate` asks it to skip any anti-flash delay because nothing is painted
      * yet.
      *
-     * Mounted unconditionally, so it must handle `visible === false` itself — and
-     * that is load-bearing rather than a style choice: the anti-flash delay is
-     * component state, so a chrome that mounted this only while loading would
-     * restart the timer on every activation and never reach it. Keep any
-     * replacement mountable-while-hidden for the same reason.
+     * Mounted unconditionally, so it handles `visible === false` itself. An
+     * anti-flash delay is component state, so a chrome that mounted this only
+     * while loading would restart the timer on every activation and never reach
+     * it. Keep any replacement mountable-while-hidden for the same reason.
      */
-    Loading: ComponentType<{
-        model: DisplayLoadingOverlayModel;
-        visible: boolean;
-        immediate?: boolean;
-    }>;
+    Loading: ComponentType<LoadingProps>;
     /**
-     * Status for work with no fetch behind it, while the phase is `ready`.
-     * Mounted unconditionally; gates on `visible` itself.
+     * Status for work with no fetch behind it, mounted only while that work
+     * runs: in the LGV chrome, a status message set while the phase is `ready`.
      *
      * **The one state that does not own its own box.** The chrome anchors the
-     * bottom-right corner and lays this out there, because that corner is shared
-     * with the display's own control row (`BottomRightIndicators`) and two boxes
-     * claiming it independently is exactly what they used to do — each pinning
-     * itself to `bottom: 2; right: 2` of the same overlay layer, the controls
-     * winning on z-index and the status text vanishing underneath. So render an
-     * **in-flow** chip: no `position`, no `inset`, no corner offsets. Sizing and
-     * colours are yours; placement is not. See `bottomRightCorner.ts`.
+     * bottom-right corner and lays this out there, sharing it with the display's
+     * own control row (`BottomRightIndicators`). So render an **in-flow** chip:
+     * no `position`, no `inset`, no corner offsets. Sizing and colors are yours;
+     * placement is not. See `bottomRightCorner.ts`.
      */
-    BackgroundProgress: ComponentType<{
-        model: DisplayBackgroundProgressModel;
-        visible: boolean;
-    }>;
+    BackgroundProgress: ComponentType<BackgroundProgressProps>;
 }

package/esm/embed/engineBoundary.d.ts

@@ -0,0 +1,34 @@
+import { Component } from 'react';
+import type React from 'react';
+export interface EngineFallbackProps {
+    error: unknown;
+    retry: () => void;
+}
+/**
+ * Catches what `useCreateViewState` rethrows from render when the engine
+ * itself cannot be built (a hub genome that does not exist, a plugin that
+ * fails to load), where there is no view yet for `ViewStatus` to draw. Wrap
+ * the component that calls the hook. `retry` remounts it, which builds again.
+ *
+ * Its own class rather than `@jbrowse/core/ui/ErrorBoundary`: a bundler groups
+ * that module with core's Material error UI, and importing it eagerly ships
+ * ~40 KB gzip of Material with the page.
+ */
+export declare class EngineBoundary extends Component<{
+    children: React.ReactNode;
+    fallback?: React.ComponentType<EngineFallbackProps>;
+}, {
+    error: unknown;
+    failed: boolean;
+}> {
+    state: {
+        error: unknown;
+        failed: boolean;
+    };
+    static getDerivedStateFromError(error: unknown): {
+        error: unknown;
+        failed: boolean;
+    };
+    retry: () => void;
+    render(): string | number | bigint | boolean | React.JSX.Element | Iterable<React.ReactNode> | Promise<string | number | bigint | boolean | Iterable<React.ReactNode> | React.ReactElement<unknown, string | React.JSXElementConstructor<any>> | React.ReactPortal | null | undefined> | null | undefined;
+}

package/esm/embed/engineBoundary.js

@@ -0,0 +1,29 @@
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { Component } from 'react';
+import { observer } from 'mobx-react';
+const DefaultFallback = observer(function DefaultFallback({ error, retry, }) {
+    return (_jsxs("div", { role: "alert", style: { padding: '10px 12px', fontSize: '0.85rem' }, children: ["Could not build the view:", ' ', error instanceof Error ? error.message : String(error), ' ', _jsx("button", { type: "button", onClick: retry, children: "Retry" })] }));
+});
+/**
+ * Catches what `useCreateViewState` rethrows from render when the engine
+ * itself cannot be built (a hub genome that does not exist, a plugin that
+ * fails to load), where there is no view yet for `ViewStatus` to draw. Wrap
+ * the component that calls the hook. `retry` remounts it, which builds again.
+ *
+ * Its own class rather than `@jbrowse/core/ui/ErrorBoundary`: a bundler groups
+ * that module with core's Material error UI, and importing it eagerly ships
+ * ~40 KB gzip of Material with the page.
+ */
+export class EngineBoundary extends Component {
+    state = { error: undefined, failed: false };
+    static getDerivedStateFromError(error) {
+        return { error, failed: true };
+    }
+    retry = () => {
+        this.setState({ error: undefined, failed: false });
+    };
+    render() {
+        const Fallback = this.props.fallback ?? DefaultFallback;
+        return this.state.failed ? (_jsx(Fallback, { error: this.state.error, retry: this.retry })) : (this.props.children);
+    }
+}