@jbrowse/core 5.0.0-beta.1 → 5.0.0-beta.10

package/esm/ui/highlightChipReveal.d.ts

@@ -1,32 +0,0 @@
-import type { MouseTracker } from './useMouseTracking.ts';
-export declare const OverlayPointerProvider: import("react").Provider<MouseTracker | undefined>;
-/**
- * The stripe a band occupies: an x span across a full-height band, a y span
- * across a full-width one. The other axis is the whole overlay, which is why it
- * isn't here.
- */
-export type HighlightStripe = {
-    left: number;
-    width: number;
-} | {
-    top: number;
-    height: number;
-};
-/**
- * Whether a band should be drawing its chip, and the `setOpen` that keeps it
- * drawn while its menu is up.
- *
- * A band reveals its chip while the pointer is in its stripe, so the highlight's
- * menu is reachable where the highlight is rather than only from the view menu,
- * and a view full of bands is not also a view full of link icons. `persistent`
- * is the `showHighlightChips` pin, which a screenshot needs because nothing
- * hovers in one.
- *
- * The menu is the reason this owns state at all: it is portalled out of the
- * band, so opening it moves the pointer off the stripe that revealed it, and
- * unmounting the chip under an open menu takes the menu's own anchor with it.
- */
-export declare function useHighlightChip(stripe: HighlightStripe | undefined, persistent: boolean): {
-    chipVisible: boolean;
-    setMenuOpen: import("react").Dispatch<import("react").SetStateAction<boolean>>;
-};

package/esm/ui/highlightChipReveal.js

@@ -1,39 +0,0 @@
-import { createContext, use, useState } from 'react';
-import { useMouseSelector } from './useMouseTracking.js';
-/**
- * The pointer over the surface a view's highlight bands are positioned in — the
- * LinearGenomeView's tracks container, the DotplotView's plot area. Published by
- * whichever of those bound the handlers.
- *
- * A context rather than a prop because a band is often drawn by another plugin
- * through an extension point (grid-bookmark's bookmark bands), and those carry
- * only their `{ model }` props bag — the band families are siblings on screen
- * and would otherwise reach the pointer two different ways.
- */
-const OverlayPointerContext = createContext(undefined);
-export const OverlayPointerProvider = OverlayPointerContext.Provider;
-function pointerInStripe(stripe, state) {
-    return 'left' in stripe
-        ? state.x >= stripe.left && state.x < stripe.left + stripe.width
-        : state.y >= stripe.top && state.y < stripe.top + stripe.height;
-}
-/**
- * Whether a band should be drawing its chip, and the `setOpen` that keeps it
- * drawn while its menu is up.
- *
- * A band reveals its chip while the pointer is in its stripe, so the highlight's
- * menu is reachable where the highlight is rather than only from the view menu,
- * and a view full of bands is not also a view full of link icons. `persistent`
- * is the `showHighlightChips` pin, which a screenshot needs because nothing
- * hovers in one.
- *
- * The menu is the reason this owns state at all: it is portalled out of the
- * band, so opening it moves the pointer off the stripe that revealed it, and
- * unmounting the chip under an open menu takes the menu's own anchor with it.
- */
-export function useHighlightChip(stripe, persistent) {
-    const tracker = use(OverlayPointerContext);
-    const [menuOpen, setMenuOpen] = useState(false);
-    const hovered = useMouseSelector(tracker, state => !!state && !!stripe && pointerInStripe(stripe, state));
-    return { chipVisible: persistent || hovered || menuOpen, setMenuOpen };
-}

package/esm/ui/promotableMenuItems.d.ts

@@ -1,19 +0,0 @@
-import type { Pin } from '../configuration/promotablePin.ts';
-import type { CheckboxMenuItem, RadioMenuItem } from './MenuTypes.ts';
-import type { RadioOption, SettingRowOptions } from './toggleMenuItems.ts';
-/** #menuBuilder promotableToggleItem | `checkboxItem` plus an apply-to-open-tracks pin */
-export declare function promotableToggleItem({ label, checked, onToggle, pin, ...opts }: {
-    label: string;
-    checked: boolean;
-    onToggle: () => void;
-    pin: Pin;
-} & SettingRowOptions): CheckboxMenuItem;
-/** #menuBuilder promotableRadioItem | `radioItem` plus an apply-to-open-tracks pin */
-export declare function promotableRadioItem({ label, checked, onClick, pin, ...opts }: {
-    label: string;
-    checked: boolean;
-    onClick: () => void;
-    pin?: Pin;
-} & SettingRowOptions): RadioMenuItem;
-/** #menuBuilder promotableRadioItems | `radioItems` plus a pin per option, from a factory over the value */
-export declare function promotableRadioItems<T extends string>(options: readonly RadioOption<T>[], current: T | undefined, setMode: (m: T) => void, pin: (value: T) => Pin): RadioMenuItem[];

package/esm/ui/promotableMenuItems.js

@@ -1,89 +0,0 @@
-import { checkboxItem, radioItem, radioItems } from './toggleMenuItems.js';
-// Every builder here describes the trailing pin (`pin`) rather than
-// rendering it. That is what keeps this module — and therefore every state
-// model and menu file that calls it — free of React and of MUI's
-// ToggleButton/Tooltip. `menuItemAdornment.tsx` turns the description into
-// `PinAdornment` at the point the menu is drawn. See
-// reference/EAGER_BUNDLE.md; `menuItems.purity.test.ts` holds it.
-//
-// Each is the plain builder in `toggleMenuItems.ts` plus a pin, and each is
-// written that way — `checkboxItem` / `radioItems` build the row — so the
-// promotable and plain forms of a row can differ only by the pin.
-// A promotable setting as one native checkbox menu row: the value toggles the
-// track (inheriting native hover/sizing/keyboard), and a trailing pin
-// (endAdornment) applies this value to every open track of the display type,
-// offering the display-type default as its snackbar's one action. Always shown
-// so the capability is discoverable.
-//
-// **The row itself is `checkboxItem`'s**, so the two builders can only ever
-// differ by the pin. They used to be two literals, and had already drifted: this
-// one accepted `helpText` and `keepMenuOpen` while silently dropping `disabled`
-// and `disabledHelpText`, so a promotable row could not be greyed out the way
-// its plain sibling could. Sharing the body is also what makes a future
-// change to what a checkbox row *is* reach both — the failure `checkboxItem`'s
-// own comment records is a menu regressing by omission.
-//
-// `keepMenuOpen` is left unset by default, so `CascadingMenu` keeps the row open
-// by its checkbox type: these rows only write a setting, users flip several in
-// one visit, and the menu is an observer so the ticks and pins move live. A row
-// whose click opens a dialog instead (colorBy's "Tag...") passes false.
-/** #menuBuilder promotableToggleItem | `checkboxItem` plus an apply-to-open-tracks pin */
-export function promotableToggleItem({ label, checked, onToggle, pin, ...opts }) {
-    return {
-        ...checkboxItem(label, checked, onToggle, opts),
-        pin: { control: pin, label },
-    };
-}
-// ONE radio row of a promotable-value group — the escape hatch, for a group the
-// plural builder below can't express. **Reach for `promotableRadioItems` first**:
-// every option in a group has to get a pin, and hand-naming the rows is what
-// leaves one without.
-//
-// The rows that genuinely need this: `pin` is optional here, for a row with no
-// single value to promote yet (the colorBy "Tag..." row before a tag is picked)
-// or a display whose slot isn't promotable at all (the shared colorBy menu on
-// gwas/variants); and the alignments size presets, whose group is gated row by
-// row (`needsContent`) and mixes in a non-promotable "Custom..." peer.
-//
-// **The row itself is `radioItem`'s**, for the reason `promotableToggleItem`'s
-// is `checkboxItem`'s: it was a second literal, and it had drifted the same way
-// its checkbox sibling had — naming `helpText`/`keepMenuOpen` by hand and so
-// silently dropping `disabled` and `disabledHelpText`, which the
-// alignments size presets have to bolt back on afterwards (`needsContent`).
-/** #menuBuilder promotableRadioItem | `radioItem` plus an apply-to-open-tracks pin */
-export function promotableRadioItem({ label, checked, onClick, pin, ...opts }) {
-    return {
-        ...radioItem(label, checked, onClick, opts),
-        ...(pin && {
-            pin: { control: pin, label },
-        }),
-    };
-}
-// A whole promotable radio group: `radioItems` plus one pin per option. The
-// plural form of the builder above, and the one to reach for on a group whose
-// options differ only in their value — which is all four of them today
-// (`heightMode`, `displayMode`, `subfeatureLabels`, `sashimiArcsMode`).
-//
-// **Every option in a group gets a pin, the `promotedBase` value included** —
-// once a non-base value is promoted, pinning the base back is the only per-value
-// way to undo it from its own row, and a radio group with one row silently
-// missing its trailing control reads as a bug. Building the group here is what
-// makes that structural instead of a rule to remember: `sashimiArcsMode`'s base
-// looked unpinnable precisely because each row had been named by hand. Prefer
-// this over `.map(promotableRadioItem)` whenever the pin is a function of the
-// option's value.
-//
-// `pin` is a factory rather than an array so it can't be a row short. Pass
-// `value => makePin(self, slot, value)`, or a model member of that shape where
-// the menu module is handed a duck-typed model (alignments).
-//
-// The rows are `radioItems`' own, so the promotable and plain groups can't drift
-// on anything but the pin. `radioItems` maps `options` in order, which is what
-// lets each row be paired back to the option that built it.
-/** #menuBuilder promotableRadioItems | `radioItems` plus a pin per option, from a factory over the value */
-export function promotableRadioItems(options, current, setMode, pin) {
-    return radioItems(options, current, setMode).map((item, i) => {
-        const { value, label } = options[i];
-        return { ...item, pin: { control: pin(value), label } };
-    });
-}

package/esm/ui/promotablePinCoverage.d.ts

@@ -1,44 +0,0 @@
-import type { ResolvableDisplay } from '../configuration/promotableResolve.ts';
-import type { MenuItem } from './MenuTypes.ts';
-import type { IAnyType } from '@jbrowse/mobx-state-tree';
-/**
- * The registered display types whose config schema declares a promotable slot,
- * sorted — the set a pin-coverage check has to reach, answered off the
- * `DisplayType`s themselves before anything is opened.
- *
- * The other half of the same gap `promotableSlotsWithoutPin` covers, and the
- * half that has no symptom at all: that function reports on a display it was
- * *given*, so a display type no fixture ever opens is not checked and does not
- * say so. Six display types declaring `showLegend` sat outside the check's
- * reach with nothing recording it.
- *
- * Takes the display types rather than a `PluginManager`, so core doesn't have
- * to name a plugin registry to answer a question about config schemas.
- */
-export declare function displayTypesWithPromotableSlots(displayTypes: readonly {
-    name: string;
-    configSchema: IAnyType;
-}[]): string[];
-/**
- * Every promotable slot some row of `items` carries a pin for, submenus
- * included.
- *
- * Reads `pin.control.slot` and nothing else. A raw `endAdornment` is
- * deliberately not counted: it is an arbitrary element (synteny's colour
- * swatch), so it cannot say which slot it promotes, and a pin built by hand
- * rather than through `promotableToggleItem`/`promotableRadioItem` is a thing to
- * find, not to accept.
- */
-export declare function pinnedSlots(items: MenuItem[]): Set<string>;
-/**
- * A display's promotable slots that its own track menu offers no pin for,
- * sorted. Empty is the healthy answer.
- *
- * Takes the built menu rather than calling `trackMenuItems()` itself, because
- * what a menu contains depends on the display's current state — a row can be
- * gated on a rendering type (wiggle line width), on a parent toggle (the sashimi
- * options), or on data having arrived. A caller that wants the whole surface has
- * to drive the display into the states that reveal it, and that is a decision
- * this function should not make silently.
- */
-export declare function promotableSlotsWithoutPin(display: ResolvableDisplay, menuItems: MenuItem[]): string[];

package/esm/ui/promotablePinCoverage.js

@@ -1,87 +0,0 @@
-/**
- * @module
- * The read side of the promotable pin: given a display, which of its promotable
- * slots its track menu actually offers a pin for.
- *
- * This exists because the two halves of the feature are declared in different
- * places and nothing joins them. Declaring `promotedBase` is a **schema** fact
- * that travels down `baseConfiguration` to every subclass; the pin is a **menu**
- * fact, built by whichever `trackMenuItems()` happens to construct a row for that
- * slot. A display that inherits the slot and curates its own menu therefore ends
- * up with a promotable slot that has no pin anywhere — and since a promoted default
- * is keyed by *display type*, no other display's pin can write its key either, so
- * the slot resolves to `promotedBase` forever unless a track customizes it.
- *
- * Nothing throws, nothing renders differently, and the config docs go on
- * advertising the setting as having a session-wide default. The state was tracked
- * by hand in `agent-docs/reference/DISPLAY_TYPE_DEFAULTS.md` and drifted twice
- * before this was written — once gaining a row for a slot that had been deleted,
- * once missing a slot that had been added.
- *
- * `products/jbrowse-web/src/tests/PromotablePinCoverage.test.ts` is the guard: it
- * opens one display of every type that declares a promotable slot and holds the
- * result against a baseline.
- */
-import { promotableSlotNames } from '../configuration/promotableSlots.js';
-/**
- * The registered display types whose config schema declares a promotable slot,
- * sorted — the set a pin-coverage check has to reach, answered off the
- * `DisplayType`s themselves before anything is opened.
- *
- * The other half of the same gap `promotableSlotsWithoutPin` covers, and the
- * half that has no symptom at all: that function reports on a display it was
- * *given*, so a display type no fixture ever opens is not checked and does not
- * say so. Six display types declaring `showLegend` sat outside the check's
- * reach with nothing recording it.
- *
- * Takes the display types rather than a `PluginManager`, so core doesn't have
- * to name a plugin registry to answer a question about config schemas.
- */
-export function displayTypesWithPromotableSlots(displayTypes) {
-    return displayTypes
-        .filter(d => promotableSlotNames(d.configSchema).size > 0)
-        .map(d => d.name)
-        .sort((a, b) => a.localeCompare(b));
-}
-/**
- * Every promotable slot some row of `items` carries a pin for, submenus
- * included.
- *
- * Reads `pin.control.slot` and nothing else. A raw `endAdornment` is
- * deliberately not counted: it is an arbitrary element (synteny's colour
- * swatch), so it cannot say which slot it promotes, and a pin built by hand
- * rather than through `promotableToggleItem`/`promotableRadioItem` is a thing to
- * find, not to accept.
- */
-export function pinnedSlots(items) {
-    const found = new Set();
-    const walk = (list) => {
-        for (const item of list) {
-            if ('pin' in item && item.pin) {
-                found.add(item.pin.control.slot);
-            }
-            if ('subMenu' in item) {
-                walk(item.subMenu);
-            }
-        }
-    };
-    walk(items);
-    return found;
-}
-/**
- * A display's promotable slots that its own track menu offers no pin for,
- * sorted. Empty is the healthy answer.
- *
- * Takes the built menu rather than calling `trackMenuItems()` itself, because
- * what a menu contains depends on the display's current state — a row can be
- * gated on a rendering type (wiggle line width), on a parent toggle (the sashimi
- * options), or on data having arrived. A caller that wants the whole surface has
- * to drive the display into the states that reveal it, and that is a decision
- * this function should not make silently.
- */
-export function promotableSlotsWithoutPin(display, menuItems) {
-    const pinned = pinnedSlots(menuItems);
-    return [...promotableSlotNames(display.configuration)]
-        .filter(slot => !pinned.has(slot))
-        .sort((a, b) => a.localeCompare(b));
-}

package/esm/util/applyInitSettings.d.ts

@@ -1,79 +0,0 @@
-import type { IAnyModelType, IStateTreeNode, SnapshotIn } from '@jbrowse/mobx-state-tree';
-/**
- * A view's init type, derived: the keys its launcher interprets (`Commands`)
- * plus every declared property of its state model, optional, in the property's
- * own snapshot type. Nothing is restated, so a property is authorable — and
- * TYPED — from the line that declares it.
- *
- * ```ts
- * export type LinearSyntenyViewInit = ViewInit<
- *   LinearSyntenyViewStateModel,
- *   LinearSyntenyViewCommands
- * >
- * ```
- *
- * THE ONE RULE THIS DEPENDS ON: the model's own `init` property must be typed
- * as the `Commands`, not as this. `init` is a property, so an `init` typed as
- * the whole thing makes the whole thing depend on itself — TS7023 on the
- * factory, then implicit-any across every file that touches the view (ADR-055,
- * same failure the view/display instance pair has). Commands never mention the
- * model, so typing `init` as those breaks the loop, and it costs nothing: the
- * view's own code reads the commands out of `self.init`, and the settings half
- * is read only by `applyInitSettings`, which asks the model rather than a type.
- */
-export type ViewInit<M extends IAnyModelType, Commands> = Commands & Partial<Omit<SnapshotIn<M>, keyof Commands | (typeof RESERVED_KEYS)[number]>>;
-export declare const RESERVED_KEYS: readonly ['id', 'type', 'init'];
-export interface InitSettingsReport {
-    /** keys applied, in the order they were found */
-    applied: string[];
-    /** keys naming no declared property — a typo, or a prop that never existed */
-    unknown: string[];
-    /** declared keys whose value the property's own type rejected */
-    invalid: string[];
-}
-/**
- * Apply the plain-settings half of an `init` blob: every key naming a declared
- * MST property of `self` is written straight to it, and the caller handles only
- * the keys it names in `commands`.
- *
- * THE POINT IS THAT THERE IS NO PER-SETTING CODE. A view used to need a
- * hand-written `if (init.x !== undefined) self.setX(init.x)` arm per property,
- * so a new toggle worked from its menu the moment it was declared and was
- * dropped in silence from every authored surface — a session spec, a share
- * link, a config `defaultSession` — until someone remembered the second edit.
- * Nobody did: `drawLocationMarkers` shipped unauthorable, and DotplotView's
- * `alpha`/`drawCigar`/`lineWidth`/`lockAspectRatio` never had an arm at all.
- * Reading the property list off the model at runtime means declaring the
- * property IS declaring it authorable, including properties a composed mixin
- * brings in (colorBy, showColorLegend), and there is nothing left to keep in
- * sync.
- *
- * `commands` is what a launcher genuinely has to interpret: keys with no
- * property behind them (`loc`, `autoDiagonalize`), keys whose name collides
- * with a property meaning something else (a spec's `views` is a list of
- * assemblies to open; the model's `views` is the built rows), and keys with an
- * ordering constraint (`levelHeights` must land after the auto-scale pass).
- * Listing one is a decision to write code for it; everything else needs none.
- *
- * WRITTEN AS A PATCH, not through `setX`. Applying init is state restoration,
- * and the authority on that is MST: `applyPatch` validates each value against
- * the property's own type and touches nothing else, where `applySnapshot`
- * would rebuild the view's children. That it skips the setters is correct
- * rather than a shortcut — a session reload restores the same state from a
- * snapshot and calls no setters either, so a property needing a setter's side
- * effect to be correct is already broken on reload, and the effect belongs in a
- * reaction on the property.
- *
- * A value the property's type rejects is dropped and reported rather than
- * thrown: init blobs come from URLs, and one bad number should not cost the
- * reader the whole view.
- */
-export declare function applyInitSettings(self: IStateTreeNode, init: object | undefined, { commands }?: {
-    commands?: readonly string[];
-}): InitSettingsReport;
-/**
- * Say what `applyInitSettings` refused, naming the surface. Split from the
- * apply so a caller under test can assert the report without a console, and so
- * the two messages read the same wherever they come from.
- */
-export declare function warnInitSettings(surface: string, report: InitSettingsReport): void;

package/esm/util/applyInitSettings.js

@@ -1,91 +0,0 @@
-import { applyPatch, getPropertyMembers } from '@jbrowse/mobx-state-tree';
-// Keys that are a view's identity or its plumbing rather than a setting. A
-// launch spec never gets to write these: `type` picks the view, `id` is passed
-// top-level so MST's optional identifier honors it, and `init` inside `init` is
-// the nesting mistake loadSessionSpec already reports.
-export const RESERVED_KEYS = ['id', 'type', 'init'];
-const RESERVED = new Set(RESERVED_KEYS);
-/**
- * Apply the plain-settings half of an `init` blob: every key naming a declared
- * MST property of `self` is written straight to it, and the caller handles only
- * the keys it names in `commands`.
- *
- * THE POINT IS THAT THERE IS NO PER-SETTING CODE. A view used to need a
- * hand-written `if (init.x !== undefined) self.setX(init.x)` arm per property,
- * so a new toggle worked from its menu the moment it was declared and was
- * dropped in silence from every authored surface — a session spec, a share
- * link, a config `defaultSession` — until someone remembered the second edit.
- * Nobody did: `drawLocationMarkers` shipped unauthorable, and DotplotView's
- * `alpha`/`drawCigar`/`lineWidth`/`lockAspectRatio` never had an arm at all.
- * Reading the property list off the model at runtime means declaring the
- * property IS declaring it authorable, including properties a composed mixin
- * brings in (colorBy, showColorLegend), and there is nothing left to keep in
- * sync.
- *
- * `commands` is what a launcher genuinely has to interpret: keys with no
- * property behind them (`loc`, `autoDiagonalize`), keys whose name collides
- * with a property meaning something else (a spec's `views` is a list of
- * assemblies to open; the model's `views` is the built rows), and keys with an
- * ordering constraint (`levelHeights` must land after the auto-scale pass).
- * Listing one is a decision to write code for it; everything else needs none.
- *
- * WRITTEN AS A PATCH, not through `setX`. Applying init is state restoration,
- * and the authority on that is MST: `applyPatch` validates each value against
- * the property's own type and touches nothing else, where `applySnapshot`
- * would rebuild the view's children. That it skips the setters is correct
- * rather than a shortcut — a session reload restores the same state from a
- * snapshot and calls no setters either, so a property needing a setter's side
- * effect to be correct is already broken on reload, and the effect belongs in a
- * reaction on the property.
- *
- * A value the property's type rejects is dropped and reported rather than
- * thrown: init blobs come from URLs, and one bad number should not cost the
- * reader the whole view.
- */
-export function applyInitSettings(self, 
-// `object` rather than a keyed record: an init blob's static type is the
-// view's own `ViewInit`, which has named members and no index signature — by
-// design, so a typo is a compile error there — and that is not assignable to
-// `Record<string, unknown>`. This reads it by enumeration anyway.
-init, { commands = [] } = {}) {
-    const report = { applied: [], unknown: [], invalid: [] };
-    if (!init) {
-        return report;
-    }
-    const skip = new Set(commands);
-    const { properties } = getPropertyMembers(self);
-    const patch = [];
-    for (const [key, value] of Object.entries(init)) {
-        if (skip.has(key) || RESERVED.has(key) || value === undefined) {
-            continue;
-        }
-        const propType = properties[key];
-        if (!propType) {
-            report.unknown.push(key);
-        }
-        else if (!propType.is(value)) {
-            report.invalid.push(key);
-        }
-        else {
-            patch.push({ op: 'replace', path: `/${key}`, value });
-            report.applied.push(key);
-        }
-    }
-    if (patch.length) {
-        applyPatch(self, patch);
-    }
-    return report;
-}
-/**
- * Say what `applyInitSettings` refused, naming the surface. Split from the
- * apply so a caller under test can assert the report without a console, and so
- * the two messages read the same wherever they come from.
- */
-export function warnInitSettings(surface, report) {
-    if (report.unknown.length) {
-        console.warn(`${surface} ignored unknown key(s): ${report.unknown.join(', ')}`);
-    }
-    if (report.invalid.length) {
-        console.warn(`${surface} ignored key(s) with an invalid value: ${report.invalid.join(', ')}`);
-    }
-}

package/esm/util/openDisplays.d.ts

@@ -1,23 +0,0 @@
-import type { ResolvableDisplay } from '../configuration/promotableResolve.ts';
-import type { AbstractSessionModel } from './types/index.ts';
-/**
- * #api core/util
- * Every display on an open track, across all open views — the reach of anything
- * that acts on "the tracks the user is looking at": a promoted default's "apply
- * to open tracks", and the share/export bake. One walk so those can't drift
- * apart.
- *
- * Recurses into composite views. A display nested in one resolves the cascade
- * like any other but was invisible to both callers, so the share/export bake
- * didn't bake its inherited values and a shared session containing a
- * breakpoint-split or synteny view rendered differently for the recipient.
- * `LGVSyntenyDisplay` is only ever reached through this branch, so don't flatten
- * the recursion away. `hasChildViews` names the one composite shape it does not
- * cover.
- *
- * A view holding neither (e.g. spreadsheet) drops out via the structural guards.
- * A view whose displays declare no promotable slot (e.g. dotplot, which does
- * hold tracks) is walked and contributes nothing — harmless, and cheaper than
- * asking each display whether it has anything to promote.
- */
-export declare function openPromotableDisplays(session: AbstractSessionModel): ResolvableDisplay[];

package/esm/util/openDisplays.js

@@ -1,79 +0,0 @@
-/**
- * @module
- * One walk of "every display on an open track, across all open views".
- *
- * Lives here rather than in `configuration/promotableDefaults.ts`, where it grew:
- * nothing about it is a cascade concern — it answers "the tracks the user is
- * looking at", and its two callers want that for different reasons (the promoted
- * default's "apply to open tracks", and `product-core`'s share/export bake). It
- * cannot move next to either one: `product-core` imports `@jbrowse/core`, never
- * the reverse.
- *
- * The displays are typed `ResolvableDisplay` because both callers immediately
- * resolve config off them, and that shape (`IStateTreeNode` + `type` +
- * `configuration`) is the smallest thing either needs.
- */
-import { isObject } from './objectUtils.js';
-import { isViewContainer } from './types/index.js';
-// A view whose open tracks we can enumerate. The generic view interface doesn't
-// surface `tracks`, so narrow structurally — the declared display shape is the
-// same ResolvableDisplay the cascade already operates on.
-//
-// Checks the elements, not just that `tracks` is an array: this narrowing is
-// what every consumer downstream trusts, and an element without `displays`
-// would put `undefined` in the walk and throw at the first `display.type` —
-// inside a share/export bake, i.e. as far from the cause as it gets. Every
-// `tracks`-bearing view today holds real track models, so this only ever
-// confirms what is already true.
-function hasOpenTracks(view) {
-    return ('tracks' in view &&
-        Array.isArray(view.tracks) &&
-        view.tracks.every(t => isObject(t) && Array.isArray(t.displays)));
-}
-// A composite view holding child views in a `views` array: breakpoint-split and
-// the linear-comparative family incl. synteny. Not exclusive with
-// `hasOpenTracks`: LinearComparativeView has both its own synteny tracks and two
-// child LGVs.
-//
-// A view that holds its children under *named* props instead (SvInspectorView's
-// `spreadsheetView`/`circularView`) is NOT reached. Enumerating a view's own
-// properties to find them isn't an option — reading every key of an MST node
-// invokes every computed view on it, several of which throw before the view is
-// initialized. No display reachable that way declares a promotable slot today,
-// so nothing is currently missed; if one ever does, give that view a `views`
-// getter returning its children rather than duck-typing harder here.
-function hasChildViews(view) {
-    return ('views' in view &&
-        Array.isArray(view.views) &&
-        view.views.every(v => typeof v === 'object' && v !== null));
-}
-function displaysInView(view) {
-    return [
-        ...(hasOpenTracks(view) ? view.tracks.flatMap(t => t.displays) : []),
-        ...(hasChildViews(view) ? view.views.flatMap(displaysInView) : []),
-    ];
-}
-/**
- * #api core/util
- * Every display on an open track, across all open views — the reach of anything
- * that acts on "the tracks the user is looking at": a promoted default's "apply
- * to open tracks", and the share/export bake. One walk so those can't drift
- * apart.
- *
- * Recurses into composite views. A display nested in one resolves the cascade
- * like any other but was invisible to both callers, so the share/export bake
- * didn't bake its inherited values and a shared session containing a
- * breakpoint-split or synteny view rendered differently for the recipient.
- * `LGVSyntenyDisplay` is only ever reached through this branch, so don't flatten
- * the recursion away. `hasChildViews` names the one composite shape it does not
- * cover.
- *
- * A view holding neither (e.g. spreadsheet) drops out via the structural guards.
- * A view whose displays declare no promotable slot (e.g. dotplot, which does
- * hold tracks) is walked and contributes nothing — harmless, and cheaper than
- * asking each display whether it has anything to promote.
- */
-export function openPromotableDisplays(session) {
-    const views = isViewContainer(session) ? session.views : [];
-    return views.flatMap(displaysInView);
-}