MultiLinearWiggleDisplay

Auto-generated @jbrowse/mobx-state-tree API for the current JBrowse release — see pluggable elements for concepts. Provided by the wiggle plugin. View source.

Example usage

The two row-ordering triggers are display properties, not config slots, so they go on the display node in a session — defaultSession here, and the same shape a session=spec- link carries. Written on the track config's own displays entry they would be dropped as unknown slots.

runClustering is a transient declarative launch spec, the same idea as LinearGenomeView's init: it runs the real "Cluster columns" RPC once automatically (no dialog) as soon as subtrack data is available, then clears itself so a saved session never re-triggers it. sortRowsBy is the other one, and the declarative form of the right-click "Sort rows by score here" — where clustering orders rows by the whole region in view, this ranks them by the score each carries at one base, so a cohort can open already ranked at a candidate locus with the surrounding context still on screen. Use one or the other; whichever applies last owns the row order.

defaultSession: {
  name: 'Copy number at CCL3L1',
  views: [
    {
      type: 'LinearGenomeView',
      init: {
        assembly: 'hg38',
        loc: 'chr17:36,080,000-36,270,000',
        tracks: [
          {
            trackId: 'pur_copynumber_1000g',
            type: 'MultiLinearWiggleDisplay',
            sortRowsBy: { refName: 'chr17', pos: 36180000 },
          },
        ],
      },
    },
  ],
}

Wiggle display overlaying/stacking multiple quantitative subtracks in one area, with optional clustering and a tree sidebar.

The configuration slots for this model are documented on its config schema page.

Members a composed model contributes are listed here too, so these tables are the whole surface.

Properties

Member	Description	Defined by
type `type: types.literal('MultiLinearWiggleDisplay')`		MultiLinearWiggleDisplay
configuration `configuration: ConfigurationReference(configSchema)`		MultiLinearWiggleDisplay
id `id: ElementId`		BaseDisplay
resolution `resolution: types.stripDefault(types.number, 1)`		WiggleCommonMixin
layout `layout: types.stripDefault(types.frozen<S[]>(), [])`		TreeSidebarMixin
clusterTree `clusterTree: types.stripDefault(types.maybe(types.string), undefined)`		TreeSidebarMixin
clusterProvenance `clusterProvenance: types.stripDefault( types.maybe(types.frozen<ClusterProvenance>()), undefined, )`	What `clusterTree` was computed from — the locus and the settings. Set only for a tree this app computed; a supplied phylogeny (maf's `.nh`) leaves it undefined. Persisted with the tree so it survives a session snapshot, which is the case that most needs it: a shared link otherwise hands over a dendrogram with no way to learn its locus.	TreeSidebarMixin
treeAreaWidth `treeAreaWidth: types.stripDefault(types.number, 80)`		TreeSidebarMixin
subtreeFilter `subtreeFilter: types.stripDefault( types.maybe(types.array(types.string)), undefined, )`		TreeSidebarMixin
runClustering `runClustering: types.maybe(types.boolean)`	Transient declarative launch spec, the same idea as `LinearGenomeView`'s `init`: a session or config sets this true and the real clustering RPC runs once automatically, with no dialog, as soon as the display reports itself ready. `setupRunClusteringAutorun` clears it afterwards, so a saved session never re-triggers. Lives here rather than on each display because it is the trigger for a run whose output — `clusterTree`, `clusterProvenance`, `layout` — is this mixin's state. Three displays declared it identically, each with its own wrapper module that existed to code-split the clustering code and, along the way, hand-wrote the same six-member duck type of the display. Splitting inside the `run` callback does the same job and loads on a run rather than on every attach. What each run actually is stays per display, in that callback.	TreeSidebarMixin
clusterRegion `clusterRegion: types.maybe(types.string)`	Where that run reads from, as a locstring (whitespace-separated for several). Clustering is region-scoped, so running it over the visible window feeds the estimator whatever happens to be on screen; naming the locus instead lets a session cluster on the signal and then show it against its context — otherwise a zoom the user has to perform in the right order. Cleared with `runClustering`, since it is that flag's argument and a locus left standing describes a run that is not coming.	TreeSidebarMixin
sortRowsBy `sortRowsBy: types.maybe(types.frozen<RowSortSpec>())`	Transient declarative launch spec, the same idea as `runClustering`: set `{refName, pos}` to order the rows once by the value each carries at that genomic column — the session-expressible form of the right-click "Sort rows by ... here". `setupRowSortAutorun` applies it once the region containing it has loaded and then clears it, so the resulting `layout` persists but a saved session never re-sorts. Where clustering orders rows by the whole region in view and `layout` states an order outright, only this one says "rank them here", which is what lets a figure open a cohort ranked at a candidate locus with the surrounding context still on screen. What the value at the column is stays per display, in its `sortRows` callback.	TreeSidebarMixin

Volatiles

Member	Description	Defined by
error `error: undefined as unknown`		BaseDisplay
statusMessage `statusMessage: undefined as string \| undefined`		BaseDisplay
statusProgress `statusProgress: undefined as number \| undefined`	determinate progress fraction [0,1] for the current status, or undefined when the in-flight phase is indeterminate. Set alongside `statusMessage` by `setStatusMessage`; a display that never shows a bar simply leaves it undefined.	BaseDisplay
scrollTop `scrollTop: 0`		TrackHeightMixin
loadedRegions `loadedRegions: regionDataMap<LoadedRegion>('loadedRegions')`	regions whose data has been fetched and committed, keyed by displayedRegionIndex; populated only after the fetch work callback returns	MultiRegionDisplayMixin
forceLoadTrack `forceLoadTrack: false`	The force-load button's track-wide approval. Volatile so it never reaches a saved session; the `forceLoad` config slot is the durable form.	RegionTooLargeMixin
byteEstimate `byteEstimate: undefined as ByteEstimate \| undefined`	The last byte measurement: bytes, the span they were taken at, and whether zooming has been shown not to shrink them. Survives `clearAllRpcData`; dropped on chromosome navigation and on a tier swap.	RegionTooLargeMixin
gateMeasuredViewportKey `gateMeasuredViewportKey: undefined as string \| undefined`	The viewport key the gate last asked the adapter about, on either axis. Separate from `byteEstimate` because a density refusal measures no bytes.	RegionTooLargeMixin
canvasDrawn `canvasDrawn: false`	flips true on first paint; read by test selectors to detect render	RenderLifecycleMixin
currentRenderingBackend `currentRenderingBackend: undefined`	current backend reference, updated on context-loss recovery. Typed `unknown` (not generic `B`) on purpose: this mixin is composed by every display via a non-generic factory, so the per-display backend type `B` isn't known here — it's supplied at `attachRenderingBackend<B>` and narrowed with `as B` inside the autoruns. Don't "fix" the cast.	RenderLifecycleMixin
renderTick `renderTick: 0`	counter the render autorun observes; bumped to force a re-render	RenderLifecycleMixin
autorunsInstalled `autorunsInstalled: false`	guards attachRenderingBackend so the autorun pair spawns once per instance	RenderLifecycleMixin
renderError `renderError: undefined`	the render-backend (GPU/Canvas2D init or context-loss) error, or undefined. Single source of truth for the render-error terminal state: `useRenderingBackend` writes it from the canvas-init mechanism so the model — not React-local hook state — owns every terminal state. Read by `displayPhase` (whose `renderError` term outranks `loading`, suppressing the scrim) and by `DisplayChrome` (shows the retry overlay).	RenderLifecycleMixin
activeStopToken `activeStopToken: undefined as StopToken \| undefined`	stop token of the in-flight fetch, or undefined when idle	FetchMixin
fetchGeneration `fetchGeneration: 0`	bumps at every fetch end; autoruns read it to re-evaluate, and it doubles as the staleness epoch inside runFetch	FetchMixin
reloadCounter `reloadCounter: 0`	Bumped by `reload()` and read unconditionally by the fetch autoruns, so a user retry re-runs the body even where nothing else moved — after an error every other fetch input is unchanged. It is also the half that survives a `reload()` override that forgets to invalidate, which is the dead Retry button `makeRetryContractCheck` reports. Declared here because this is the one mixin both LGV fetch foundations compose, the same argument that put `fetchInert` below; the comparative family carries its own on `SyntenyFetchStateMixin` (ADR-054).	FetchMixin
statusWindow `statusWindow: createStatusWindow(writeStatus(self))`	This display's status field, and the only thing that writes it: one throttle window, one slot per concurrent operation, so N parallel per-region fetches thin to one stream between them rather than N and a second operation cannot end the first one's label (ADR-081). Lent whole to `createStopTokenRotation` by a display that also runs a bare-autorun fetch — see `StatusReporter`.	FetchMixin
fetchCanceled `fetchCanceled: false`	true after the user explicitly cancels a load (the loading overlay's cancel button → `cancelFetchByUser`). A durable, blocking state — unlike `cancelFetch`, it does not retrigger the fetch autoruns — so the load stays stopped until the user retries (`reload`) or the viewport changes. Any new fetch clears it (`runFetch` resets it at the start).	FetchMixin
fetchRotation `fetchRotation: createStopTokenRotation(self, { statusWindow: self.statusWindow, })`	The latest-wins machine this mixin is a wrapper around, and not a second one: `createStopTokenRotation` owns token rotation, the `isCurrent` guard, the status slot and the supersede-versus-end rule (ADR-080, ADR-081), for every fetch in the codebase that has one. `runFetch` adds the observable bookkeeping a display needs on top — `isLoading`, `error`, `fetchGeneration`, `fetchCanceled` — and nothing else. It was two implementations of that machine until 2026-08-20, which is how they came to disagree about whether a completed fetch releases its token. A display's primary fetch is this wrapper; a second concurrent fetch on the same node holds a rotation of its own, which is why the primitive is the thing that exists and this is the thing built on it (ADR-054 §1). It is lent this display's `statusWindow`, so the fetch takes a slot on the one field rather than opening a second window over it — the whole point of `StatusReporter`.	FetchMixin
rpcDataMap `rpcDataMap: regionDataMap<WiggleDataResult>('rpcDataMap')`		WiggleCommonMixin
hoveredWiggleFeature `hoveredWiggleFeature: undefined as WiggleHoveredFeature \| undefined`	The stored hit. Named apart from the `hoveredFeature` getter below it fills, because `BaseDisplay` declares that hook as a computed and MST refuses to instantiate a volatile over one — a display filling it stores under its own name and exposes a getter, which is what canvas, alignments and the variant displays already did.	WiggleCommonMixin
hoveredTreeNode `hoveredTreeNode: undefined as HoveredTreeNode \| undefined`		TreeSidebarMixin
treeCanvas `treeCanvas: null as HTMLCanvasElement \| null`		TreeSidebarMixin
mouseoverCanvas `mouseoverCanvas: null as HTMLCanvasElement \| null`		TreeSidebarMixin
contextMenuInfo `contextMenuInfo: undefined as Info \| undefined`		ContextMenuMixin

Getters

Member	Description	Defined by
isDensityMode `boolean`		MultiLinearWiggleDisplay
isOverlay `boolean`		MultiLinearWiggleDisplay
sourcesWithoutLayout `SourceInfo[]`		MultiLinearWiggleDisplay
editableSources `SourceInfo[]`		MultiLinearWiggleDisplay
sources `SourceInfo[]`		MultiLinearWiggleDisplay
numSources `number`		MultiLinearWiggleDisplay
autoscaleSourceNames `Set<string>`		MultiLinearWiggleDisplay
legendItems `LegendItem[]`	The color key, as the shared `LegendSpec` items every other display publishes — one row per (group, color) pair, colors resolved. The on-screen `FloatingLegend`, the SVG export and `overlayLegendApplies` all read this one list, so what is drawn and what was counted before deciding to draw cannot disagree. See `buildLegendItems`.	MultiLinearWiggleDisplay
effectiveRowHeight `number`	Resolved per-row height. This display is always fit-to-display-height — there is no pinned-height setting and so no `rowHeight` sentinel to resolve — but it carries the same name every row display exposes its resolved height under (see agent-docs/reference/ROW_HEIGHT_AND_FIT), which is also what tree-sidebar's `TreeDrawingModel` reads.	MultiLinearWiggleDisplay
numRows `number`	Rows actually drawn: overlay collapses every source onto one shared plot. Read by the render state and by everything that repeats itself per row (scalebars, cross hatches), so they can't disagree about how many rows exist.	MultiLinearWiggleDisplay
rowHeightTooSmallForScalebar `boolean`		MultiLinearWiggleDisplay
plotGeometry `{ yTop: number; plotHeight: number; numRows: number; tickHeight: number; }`	Rows stacked edge-to-edge over the full height, no scalebar-label inset (unlike single-wiggle): the axis is drawn per row and maximum density is the point. Each row's own box is what the ticks are laid out in.	MultiLinearWiggleDisplay
scoreRampApplies `boolean`	Only density spends color on the score, and only when every row shares the one ramp: a source with its own color is drawn on its own pos side (see buildSourceRenderData), so a single bar would describe none of them.	MultiLinearWiggleDisplay
showRowSeparators `boolean`		MultiLinearWiggleDisplay
overlayLegendApplies `boolean`	Whether the source color key applies at all. Gates the menu checkbox, which has to stay visible while the legend is toggled off. Four questions in order, each with its own guard below: 1. Is there anything to key? One source names itself by the track name. 2. Does anything ELSE on the frame name the colors? Overlay collapses every source onto one plot, so nothing does and a key is the only identification there has ever been. A multi-row track names its rows beside them — but only while they carry text (`rowLabelsCarryText`, asked of the drawing side rather than restated) AND is drawing them at all — `showRowLabels` off means nothing beside the rows names anything, so the key is once again the only identification there is. Below that `SvgRowLabels` drops to an unlabelled swatch, and a per-cell density track at 0.14 px a row is then a stripe of nine colors with nothing saying what any of them is; that is the case this was widened for ("we need to make it so density can show legend also ideally because the left side labels are too small to see"). `showTree` is deliberately no part of this: the labels are `MultiWiggleSvgScales`' own and draw whether or not a dendrogram does, so reading it here drew a key restating labels still on screen. 3. Is the key worth its rows? Short enough to read, and made of more than one color — both `legendIsReadable`, shared with the other display that has to decide. Asked of `legendItems`, the very list that gets drawn, so a key can't be counted in one form and rendered in another.	MultiLinearWiggleDisplay
prefersOffset `boolean`	Offset the track label above the visualization so the stacked per-source rows aren't hidden behind an overlapping label.	MultiLinearWiggleDisplay
hasOverlayLegend `boolean`	Whether the overlay color key actually draws. The on-screen overlay and the SVG export both read this, so a dismissed legend can't linger in the export.	MultiLinearWiggleDisplay
hierarchy `ClusterHierarchyNode \| undefined`	The positioned dendrogram, or undefined in an overlay mode: overlay collapses every source onto one row, so a tree spreading its leaves over the full height would align to nothing. This is the single gate — the on-screen sidebar, the SVG export, `spatialIndex` (subtree hover), and `treeSidebarRightEdge` (the tooltip/crosshair dead zone the sidebar reserves) all read it, so none of them can keep drawing or reserving space on their own. A subtree filter set in a row mode still applies and is still clearable from the track menu and MultiWiggleHint.	MultiLinearWiggleDisplay
spatialIndex `TreeSpatialIndex \| undefined`		MultiLinearWiggleDisplay
parentTrack `AbstractTrackModel`		BaseDisplay
RenderingComponent `FC<…>`		BaseDisplay
DisplayBlurb `FC<{ model: ModelInstanceTypeProps<{ id: IOptionalIType<ISimpleType<string>, [undefined]>; type: ISimpleType<string>; }> & { ...; } & { ...; } & IStateTreeNode<...>; }> \| null`		BaseDisplay
adapterConfig `Record<string, unknown>`		BaseDisplay
isMinimized `boolean`	Returns true if the parent track is minimized. Used to skip expensive operations like autoruns when track is not visible.	BaseDisplay
hoveredFeature `unknown`	Overridable hook (default `undefined`): what the pointer is currently over, for readers outside the display. `LinearGenomeViewContainer` publishes it to `session.hovered`, the view-wide "what is the user pointing at" channel a plugin can subscribe to. Declared here because a cross-display consumer can only read a name the base declares — the same reason `SyntenyFetchStateMixin.fetchInert` is a hook rather than a getter each display invents. The container used to read `featureUnderMouse`, which only the wiggle, alignments and Manhattan families spelled that way — canvas said `hoveredFeature`, variants `hoveredGenotype` — so the channel carried a hover from a third of the display types and nothing said which. It also asked only `displays[0]` of each track. `unknown` because the payload genuinely differs — a read, a wiggle bin, a SNP, a genotype cell — and `session.hovered` is typed to match ("can be anything; code that wants to deal with this should examine it"). Narrow it in the override.	BaseDisplay
featureNoun `string`	Overridable hook (default `'feature'`): the SINGULAR word for one of the things this display draws, as a menu row or a chip says it — "Hide this read", "Showing 3 variants". Declared here for the same reason as `hoveredFeature` above: it is read across the display boundary, by chrome that has no idea which display it is drawing for (`SoloSelectionChip`, alignments' group-label overlay), and a name only the base declares is a name every such consumer can rely on. Two displays declared it independently and one of those declarations WAS this default. A control keeps the generic word; content takes this one. "Variant height" reads as a different setting from "Feature height" when it is the same one, so the shared menus stay on "feature" however the display answers here, and the noun varies where it names what the user is looking at — "Showing 3 variants", "Hide this read". A display drawing something the generic word already fits is right to leave this alone. Distinct from the per-hit noun a context menu takes off the clicked item's own `type` ("mRNA", "gene"); that names one annotation, this names what the track holds. The hit noun falls back to this.	BaseDisplay
featureWidgetType `{ type: string; id: string; }`	Overridable hook: which widget `openFeatureWidget` opens for one of this display's features. The default is the generic one, which is what a display drawing plain features wants and what the canvas base spelled out by hand. An override is a display whose features have a vocabulary of their own — a read, a variant, a synteny block — and the `id` is deliberately part of it: two displays naming one id share the drawer panel, which is the behaviour when the two are showing the same kind of thing.	BaseDisplay
height `number`		TrackHeightMixin
resizing `boolean`	True for the duration of a height drag on this track, whichever handle is running it. A display whose row geometry is a function of the track height restretches every row per animation frame, and can use this to sit an expensive per-frame layer out of the drag (MAF's dense per-base letter overlay is a Canvas2D pass that scales with rows x columns). The flag itself is the track's (`BaseTrackModel`), so the view brackets a drag without needing the active display to have opted into this mixin. Reading it here is what makes `self.resizing` available to a display that did.	TrackHeightMixin
scrollableHeight `number`	Overridable hook: how far this display's content can scroll past its viewport, in px. `Infinity` (the default) means "this display doesn't scroll internally" — `setScrollTop` then never clamps and the re-clamp autorun below is inert, so a non-scrolling display pays nothing and, crucially, never evaluates a getter that would read view geometry. A display that scrolls a canvas overrides this with `max(0, contentHeight - viewportHeight)`, and gets the clamped setter plus the shrink autorun for free. It is the single "does it scroll, and by how much" answer: the wheel handler (`useVirtualScrollWheel`) and `VerticalScrollbar` read the same getter.	TrackHeightMixin
host `RegionHost`	The containing LinearGenomeView, typed once for every display in this family — see `containingHost` for the cast it owns and why both foundations still declare the name.	MultiRegionDisplayMixin
canvasWidthPx `number`	The CSS width of this display's on-screen canvas, in px — and the `canvasWidth` its `renderState` must carry, since the two have to agree or the bp→px mapping is scaled against a box it doesn't fill. `trackWidthPx`, not `view.width`: `TrackRenderingContainer` insets the rendering component by the 2px track outline under `contain: strict`, so a `view.width`-wide canvas overhangs its own container and the browser clips the overhang away. It renders almost identically, which is why MAF drifted onto `view.width` uncaught. A getter rather than a note on each display, because the choice was being made by copying a neighbour out of four plausible view getters — `width` (the viewport), this one, and `totalWidthPx` / `totalWidthPxWithoutBorders` (the content width, which the global family's heatmaps legitimately want: a different question, not a different answer). `no-restricted-syntax` bans the underlying read everywhere but this line, since a second spelling agrees until it doesn't. SVG export is the one exception: the export shell has no outline, so `renderSvg` overrides `canvasWidth` with the shell's own width (see `LgvSvgBodyProps`).	MultiRegionDisplayMixin
canRender `boolean`	Overrides `RenderLifecycleMixin`'s default-true hook with the LGV precondition both foundations share — see `foundationCanRender`.	MultiRegionDisplayMixin
viewportWithinLoadedData `boolean`	true when every visible block lies within an already-fetched region — i.e. the viewport shows data we actually loaded, not the stale fringe left after a zoom-out/pan. Drives the loading overlay through the pre-refetch debounce. Spatial only, and it stays that way. Whether the data held for a block is still what a fetch would bring back is `isCacheValid`, which `dataCurrent` conjoins for the export gate. The scrim reads this getter alone: a phase that went `loading` on a moved `regionFetchKey` would raise the overlay into every zoom.	MultiRegionDisplayMixin
viewportEmpty `boolean`	No content block is on screen, so this display has nothing to fetch and nothing to paint — see `viewportEmpty.ts` for the one viewport that reaches it, how narrow that is, and why the state still has to be terminal rather than a permanent scrim. Both foundations declare it over that one expression, the same way they each declare `host` and `paintInert`.	MultiRegionDisplayMixin
layoutReady `boolean`	Overridable hook (default false): whether a searchable feature layout currently exists. Any display defining a feature-lookup method (`searchFeatureByID`, `getFeatureById`) must override it, so callers can tell "laid out, but off-display" from "no layout exists yet" — a distinction only the display can make. See packages/display-kit/CLAUDE.md §"Four readiness axes".	MultiRegionDisplayMixin
regionFetchKey `string`	Overridable hook (default `''`): what a fetch issued right now would produce for a region, as a string — the display's per-region content axis. `fetchRegions` captures it before it issues the RPC and stamps it beside the loaded region; `isCacheValid` refetches a region whose stamp no longer matches. Wiggle returns `String(view.bpPerPx)` (adr-008), canvas the peptide-overlay threshold, the variant matrix its zoom in matrix mode only. NOT an `rpcProps()` field: this invalidates one region's held data where `rpcProps` invalidates all of it, and a zoom-swinging value in the RPC payload blanks the display at the force-load floor — see REGION_TOO_LARGE.md §"How the verdict is built". A getter, so the observables it reads register as dependencies of `FetchVisibleRegions`; MobX runs an action untracked and the autorun would keep a stale answer.	MultiRegionDisplayMixin
dataSuperseded `boolean`	Overridable hook (default false): the held data is loaded and covers the viewport, but a fetch input has moved past it, so the data is about to be cleared and refetched. A display says so here rather than overriding `dataCurrent`, for the reason `FetchMixin.fetchInert` is a hook: an override has to restate the freshness terms and then misses the next one added. On screen this window is invisible (the clear lands a tick later and the loading scrim covers it), which is exactly why it needs saying: `awaitSvgReady` samples freshness once, and an export that samples it inside this window renders the data that is about to be discarded — or, once the clear lands mid-render, nothing at all. GWAS's LD auto-index is the case: adopting the top hit as the index SNP is an `rpcProps` change, so the very load that produced the top hit is what it invalidates. The input need not have settled yet. Alignments counts the debounce window ahead of its per-base bin, where the bin the data was fetched under has not moved and the clear is inevitable rather than committed. That is the half of the window an export lands in, since a reader zooms and then reaches for the menu. What may NOT go in is a change that could still be taken back: this fails hung, not stale. So state the live-vs-settled half as a value compare and leave key strings alone. The settled half — the stamp a fetch committed under against the key a fetch now would use — is the foundation's already, through the `isCacheValid` term in `dataCurrent`, and an override restating it buys nothing: a second derivation of the key's vocabulary reads `"16\|fine"` against a live `"16"` the day the key grows an axis, latches this true, and every export of the display then waits out `awaitSvgReady`'s backstop instead of failing.	MultiRegionDisplayMixin
renderBlocks `RenderBlock[]`	Shared cached view for every LGV-based GPU display. A single displayedRegion may produce multiple render blocks (shared GPU buffer, different scissor clips on screen). Plugins that want to suppress rendering in certain states (e.g. no domain yet) can override this getter to return [] — the autorun lifecycle will then issue an empty-blocks render that clears the canvas.	MultiRegionDisplayMixin
dataCurrent `boolean`	This family's answer to the shared freshness question every display foundation must answer (`dataCurrent`): the held data corresponds to what is on screen right now. Four terms — spatial coverage of every visible block, `loadedRegions.size` to rule out the vacuously-true empty viewport, `isCacheValid` per block, and the display's own `dataSuperseded`. Regions stream in one at a time, so this (not "the first datum arrived") is what keeps a multi-region/whole-genome export complete. `isCacheValid` belongs here and not in the scrim. Coverage answers "is the data here", never "is it what a fetch now would bring back", so a zoom that moves `regionFetchKey` leaves every held region covered and stale at once — and an export sampling `svgReady` across that window painted bins the worker computed for the previous zoom. `displayPhase` still reads `viewportWithinLoadedData` alone: folding staleness into the phase raises the loading scrim into every zoom, which is the trade REJECTED_IDEAS.md "Folding content staleness into `displayPhase`" turned down and this does not take. The term cannot latch, and the reason is structural rather than a case list: a block reaches `fetchNeeded` unless `planRegionFetch` finds it ungated, covered AND cache-valid, and it reads that last term tracked. The `&&` short-circuits ahead of it drop its observables only where the block is fetched anyway, so the key move that closes this gate is the same read, in the same dependency set, that wakes the refetch reopening it.	MultiRegionDisplayMixin
loadedAssembly `(ModelInstanceTypeProps<…> & { error: unknown; loadingP: Promise<…> \| undefined; ... 10 more ...; refNameMismatches: Map<…>; } & ... 13 more ... & IStateTreeNode<...>) \| undefined`	The assembly the data in hand came from, once it can answer about refNames — `undefined` before that. Off the first LOADED region rather than the view's displayed ones, which is the distinction that makes it belong here: a display holding fetched data is asking about the assembly THAT data is on, and the view's regions can already have moved on. The `initialized` gate is why this returns the assembly rather than its name. `getCanonicalRefName2` and `refNameToIndex` answer WRONGLY rather than throwing before the aliases land — identity, and a miss — so a caller that skips the gate gets a plausible answer and no signal. Handing back `undefined` until it can answer is what makes the caller write its fallback.	MultiRegionDisplayMixin
svgReady `boolean`	true once an off-screen (SVG) export can safely read this display's data. Policy single-sourced in `computeSvgReady`; this family supplies only the freshness half, which `foundationSvgReady` reads as `dataCurrent` or the vacuous currency of `viewportEmpty`. Off-screen renderers gate on it via `awaitSvgReady(model)` instead of inlining the condition.	MultiRegionDisplayMixin
paintInert `boolean`	Fills `RenderLifecycleMixin`'s `paintInert` hook — see there for why a failed fetch has to read as finished to the consumers outside the display, and `foundationPaintInert` for the second such state and why both fetch families answer it through one function. Overridable, as the hook is: a display with a third inert state of its own says so here.	MultiRegionDisplayMixin
displayPhase `DisplayPhase`	The display's mutually-exclusive visual state, mapped in `foundationDisplayPhase` — every foundation calls it and supplies only its staleness argument, so a term added to `computeLoadingTerm` reaches all three without being wired three times. This family's argument is spatial: `loading` also covers stale data (viewport past loaded) still on screen through the pre-refetch debounce. A thunk, so a suppressed or already-loading display doesn't subscribe to viewport churn. A subclass customizes this through `fetchInert` (FetchMixin), never by overriding the getter — see that hook.	MultiRegionDisplayMixin
gateEnabled `boolean`	The opt-in. Overridden with a literal `true` by gated displays, and `check-gated-adapter-budgets` insists on a literal: this mixin returns early on it in an autorun and in `commitFetchBytes`.	RegionTooLargeMixin
densityGateEnabled `boolean`	Whether the density axis applies. `CanvasFeatureGateMixin` contributes `true` beside its measurement; byte-only displays leave it.	RegionTooLargeMixin
byteGateAdapterConfig `Record<string, unknown>`	The adapter config the gate measures — the one at `byteGateAdapterPath`. Overridable for a display whose adapter config is synthesized rather than read off the track.	RegionTooLargeMixin
configuredFetchSizeLimit `number`	The display's `fetchSizeLimit` slot, from `regionTooLargeConfigSchemaFields`.	RegionTooLargeMixin
densityTooLarge `boolean`	The density axis's verdict; canvas overrides it.	RegionTooLargeMixin
byteGateAdapterPath `string[]`	Where on the track config the measured adapter sits. A tiered display overrides this one hook (MAF: `['adapter', 'summaryAdapter']` while `showSummary`), and both the measurement and the budget follow it.	RegionTooLargeMixin
adapterFetchSizeLimit `number \| undefined`	The measured adapter's own `fetchSizeLimit` slot, read off the live track config rather than the `adapterConfig` snapshot, which omits slots at their default.	RegionTooLargeMixin
configForceLoad `boolean`	The declarative `forceLoad` slot.	RegionTooLargeMixin
gateViewport `GateViewport \| undefined`	What a measurement taken now would be about: the span on screen and a key for the stretch of genome it covers. Undefined until the view is measured, and the mixin's only read of the view. Captured before the fetch's round trip, never at commit.	RegionTooLargeMixin
byteGateAdapterKey `string`	Which tier the estimate is about, as a comparable string.	RegionTooLargeMixin
aboveForceLoadFloor `boolean`	Whether the span on screen is at or above `AUTO_FORCE_LOAD_BP`, the one comparison against that constant. False on an unmeasured view.	RegionTooLargeMixin
gateExempt `boolean`	Nothing may gate on either axis: the `forceLoad` slot or the button.	RegionTooLargeMixin
estimatedFetchBytes `number \| undefined`	The stored estimate's bytes; undefined when nothing has been measured.	RegionTooLargeMixin
gateMeasurementStale `boolean`	Whether the last measurement is about a viewport the user has since left. True before any measurement.	RegionTooLargeMixin
gateByteLimit `number`	The byte budget: the adapter's limit, else the display's, doubled below `AUTO_FORCE_LOAD_BP`. Read only through `resolvedByteLimit()`.	RegionTooLargeMixin
gateActive `boolean`	Whether the gate may act right now, on any axis: opted in, not exempt, view measured. The view is read last, so an ungated display never touches it.	RegionTooLargeMixin
densityGateActive `boolean`	`gateActive` plus the density axis's own terms: the axis is on, and the span is above the floor.	RegionTooLargeMixin
tooLargeStatus `RegionTooLargeStatus`	The verdict and its banner text, from the stored estimate against `resolvedByteLimit()` and the density axis when it may act.	RegionTooLargeMixin
regionTooLarge `boolean`		RegionTooLargeMixin
regionTooLargeReason `string`	Banner text for the axis that tripped; empty when not too large.	RegionTooLargeMixin
zoomCanReleaseGate `boolean`	Whether "zoom in to see features" is honest advice. Density always releases on zoom; bytes only if the last zoom-in moved the estimate.	RegionTooLargeMixin
gateSkipsMeasuredViewport `boolean`	The skip both fetch skeletons apply: the banner is up and its measurement already describes the viewport on screen.	RegionTooLargeMixin
rendersCanvas `boolean`	Overridable hook (default true): whether this display paints a canvas in its current configuration, as opposed to a deliberate static placeholder (LD with the triangle off, sequence past base resolution — both render a message where the `<canvas>` would go, so `canvasRef` is never called and `canvasDrawn` can never flip). Lives here, beside `canvasDrawn`, because every consumer of "has this display painted" needs the pair — and until 2026-08 each family declared its own copy (per-region hard-coded `true`, global carried the hook for LD), so a display could express the state only to whichever family it happened to compose. See `painted` below for the reader that was missed.	RenderLifecycleMixin
painted `boolean`	The first-paint answer every consumer outside the display should read, `canvasDrawn` being only the raw flag: a display that is deliberately not painting a canvas has finished, and saying otherwise is a lie that never resolves. The two `rendersCanvas: false` states each had three of their four consumers wired by hand — the loading scrim (`rendersCanvas` / `fetchInert`) and the SVG export (`fetchInert`) — while the fourth, `data-display-drawn`, went on publishing `"false"` forever off the raw flag. That attribute is what `PENDING_DISPLAYS` (`@jbrowse/browser-test-utils`) selects on, so a zoomed-out reference sequence track made every `waitForDisplaysDone` on the page burn its full timeout — silently, since that wait swallows its own. Same shape as `fetchInert` on the comparative side: the reader you forget is the one outside the display, so the display has to publish one name for it. `paintInert` is the third term and the same argument once more, for the state where a display would paint a canvas and never gets to — a fetch that failed before first paint. See that hook.	RenderLifecycleMixin
isLoading `boolean`	true while a fetch is active	FetchMixin
isLoadingOrCanceled `boolean`	`isLoading` widened to cover a user-canceled load. This, not `isLoading`, is what a `displayPhase` loading term wants. `cancelFetchByUser` clears the stop token synchronously, so `isLoading` goes false the instant the user clicks Cancel — and the loading overlay that unmounts on it is carrying the Retry button, which is the only way back: the state is deliberately durable, so no autorun restarts the fetch on its own. A bare `isLoading` therefore reads as `ready` over a display that is stopped, empty and offering nothing. Arc read `isLoading` directly and had exactly that hole. It is a getter here so no family has to remember the second term.	FetchMixin
fetchInert `boolean`	Overridable hook (default false): the states where this display deliberately never fetches, so it holds no data and none is coming. Sequence sets it past base resolution ("Zoom in to see sequence"); LD sets it with the triangle toggled off. One hook, three readers, and that is the whole point — a display that grows such a state has one thing to say rather than three, and the reader it would have forgotten is always the one outside itself: - the loading scrim (`computeLoadingTerm`), which otherwise parks over the placeholder, permanently once a cancel has been clicked; - the SVG export (`computeSvgReady`'s `extraTerminal`), whose `awaitSvgReady` is an unbounded `when`, so one such display hangs the whole view's export; - the dev-only retry check (`makeRetryContractCheck`), which would otherwise report a dead Retry on a display correctly declining to load anything. It was three hooks — `loadingSuppressed`, `svgReadyExtraTerminal` on each of the two foundations, and `fetchInert` on the comparative family, which had already collapsed them. Both LGV displays that override it returned one expression for all three, and one of the three was hard-coded `false` on the global family for a while, which is how LD came to be able to express only half its own state. Same name and same meaning as `SyntenyFetchStateMixin.fetchInert` now, so the retry check reads one field across all three fetch families. ADR-082. A hook rather than a `displayPhase` override, because overriding the getter means restating the whole loading condition — which is how sequence came to hold a verbatim copy of the other terms, one `git blame` away from silently missing the next one added. It lives here because this is the one mixin all three display foundations compose. Same argument, one level down, that put `rendersCanvas` on `RenderLifecycleMixin` beside `canvasDrawn`.	FetchMixin
awaitingPrerequisite `boolean`	Overridable hook (default false), read only by the dev-only retry check (`makeRetryContractCheck`): "this run declined because a prerequisite fetch in another autorun has not landed, and its arrival wakes this one again". It defers the retry verdict to that later run rather than waiving it, so a display cannot spend its retry on a decline it called preliminary. Two displays say it, one per fetch foundation, which is why it lives beside `fetchInert` rather than on either: HiC's contacts fetch declines until `CoreGetInfo` lands, and `MultiSampleVariantBaseModel`'s `fetchNeeded` declines until `sourcesBase` does. Both have a `reload()` that wakes the prerequisite's autorun as well as their own. It has to be strictly narrower than the gate it explains. One that restates the gate's negation makes every decline a deferred one, so no run is ever judged and the display has silently opted out — an exemption by another name. HiC is in that shape deliberately, because its gate and its prerequisite are one condition; what covers its retry instead is `LinearHicDisplay/infoFetchFailure.test.ts`. Not for a display deliberately not fetching at all — that is `fetchInert` above, which the loading scrim and the export read too.	FetchMixin
rpcPropsCacheKey `string`	The RPC cache key both fetch foundations invalidate on: this display's `rpcProps()` payload serialized to a string. `serializeRpcProps` owns the why, including the silently-dead-axis corollary. Here, beside the two hooks above, for the same reason they are: it describes the display, and every foundation composes this mixin. The per-region family watches it from `SettingsInvalidate` and the global one from its fetch autorun's trigger list — one getter and one name, so the two cannot come to invalidate on different axes. The global side built its own local `computed` over the same function until 2026-08, which was the same value under a second spelling.	FetchMixin
symlogConstant `number`	Raw `symlogConstant` slot; `0` means "derive from the domain". Resolve it with `resolveSymlogConstant` once the domain is known. Here rather than on `WiggleScoreConfigMixin` because the slot is in `wiggleConfigSchemaFields`, which is this mixin's host table. It sat one level up, whose OTHER composer is `LinearManhattanDisplay` -- linear-only by construction, so its schema declares no `symlogConstant` and the getter answered `undefined` while typed `number`. Inert, because nothing on that path reads it, and invisible: `getConf` on an undeclared slot returns `undefined` and reports nothing at any layer. That is the same reasoning the getter already carried for moving off `ScoreScaleMixin` (the alignments coverage band composes that against a schema that never declares it) -- it just stopped one mixin too high.	WiggleCommonMixin
posColor `string`		WiggleCommonMixin
negColor `string`		WiggleCommonMixin
bicolorPivot `number`		WiggleCommonMixin
numQuantile `number`		WiggleCommonMixin
lineWidth `number`		WiggleCommonMixin
maxGapMultiple `number`	Interpolated-line gap threshold, as a multiple of the track's own mean point spacing (see gapBreakLimit). 0 keeps one connected line.	WiggleCommonMixin
summaryScoreMode `string`		WiggleCommonMixin
renderingType `string`		WiggleCommonMixin
minimalTicks `boolean`		WiggleCommonMixin
hasResolution `boolean`		WiggleCommonMixin
effectiveSummaryScoreMode `string`	The summary mode actually drawn. Density has no whiskers presentation — `sourceLayers` falls back to the average scores — so the autoscale domain reads this rather than the raw slot; otherwise the color ramp spans the whisker extremes while the plot paints averages, and the score legend reports a range nothing on screen reaches. Single-wiggle defaults to whiskers, so plain "plot type → Density" hit this.	WiggleCommonMixin
scoreRuleValues `number[]`	Scores the axis must reach whatever the data does, so a rule drawn at one stays on it. `[]` here and overridden by the displays that draw score rules — MultiLinearWiggleDisplay stacks a plot box per row and draws none, so it keeps the base.	WiggleCommonMixin
domain `[number, number] \| undefined`	The autoscaled domain over the sources visible in the settled blocks. `undefined` until the view and the data are ready, which is not the `[0, 1]` a caller falls back to — see `visibleStatsDomain`.	WiggleCommonMixin
scatterPointSize `number`		WiggleScoreConfigMixin
displayCrossHatches `boolean`	The configured cross-hatch setting. A config slot rather than a display prop — like `scatterPointSize` beside it — because a prop cannot be set from a config at all: MST drops a snapshot key the schema never declares, so `demos/cgiab` had asked for hatches on its CNV track and never got them. Read `showCrossHatches` below for what actually draws; this is the raw setting the menu toggles.	WiggleScoreConfigMixin
showCrossHatches `boolean`	Whether the score-axis cross hatches draw. Density spends color, not height, on the score, so there is no axis for them to rule — and the track menu drops the toggle there, which would strand hatches enabled in another plot type with no way to turn them off. Every consumer (on-screen overlay, multi-row overlay lines, SVG export) reads this, never the raw `displayCrossHatches` setting.	WiggleScoreConfigMixin
scaleType `string`		ScoreScaleMixin
autoscaleType `string`		ScoreScaleMixin
numStdDev `number`		ScoreScaleMixin
minScore `number`	Raw slot value, sentinel intact — see the class comment.	ScoreScaleMixin
maxScore `number`	Raw slot value, sentinel intact — see the class comment.	ScoreScaleMixin
defaultScoreDomain `[number \| undefined, number \| undefined]`	Overridable hook: what each end of the domain falls back to where the config leaves its bound unset. `[undefined, undefined]` — the default — means autoscale both ends, which is right for a track whose scores have no absolute meaning (a bigwig's units are its own). A display whose scores are bounded by construction overrides it, so the axis stops being a function of what happens to be on screen: GC content is a fraction, so 0 and 1 are its real limits and mean the same thing at every locus. Autoscaled, the same GC value drew at different heights depending on where the user had panned, and the track could not be read across loci. A hook rather than a config default because the answer can depend on display state — GC's does, on `gcMode` — and rather than each display re-resolving the sentinels below, which is the one thing that must not be duplicated: config bounds still win, precisely because they are checked before this is consulted.	ScoreScaleMixin
minScoreBound `number \| undefined`	Resolved lower bound; `undefined` means autoscale this end.	ScoreScaleMixin
maxScoreBound `number \| undefined`	Resolved upper bound; `undefined` means autoscale this end.	ScoreScaleMixin
showLegend `boolean`	Whether the legend is drawn. Resolved through the promotable-slot tiers (`resolveConf`): an explicit track value customizes it either way, otherwise it follows the session-wide default for this display type, falling back to the slot's `promotedBase`.	LegendMixin
showLegendDisplayTypeDefault `Pin`	The "make the current legend visibility the default for all tracks" control. Symmetric, so it promotes whichever value the track currently shows. `showLegendCheckboxItem` takes this as its `pin`.	LegendMixin
showTree `boolean`	Whether the dendrogram sidebar is drawn.	TreeSidebarMixin
showBranchLength `boolean`	Whether tree nodes are positioned by branch length (dendrogram) or evenly by topology (cladogram).	TreeSidebarMixin
showRowLabels `boolean`	Whether each row's name is drawn over the left of the plot.	TreeSidebarMixin
parsedTree `HierarchyNode<NewickNode> \| undefined`		TreeSidebarMixin
root `HierarchyNode<NewickNode> \| undefined`		TreeSidebarMixin
treeHasBranchLengths `boolean`		TreeSidebarMixin
rowOrderIsCustom `boolean`	Whether the rows have been arranged away from the order they arrived in — what "Reset row order" is offered on. A written `layout` here; a display whose config seeds `layout` on load (the multi-sample variant displays' `colorBy` / `groupBy`) overrides it to compare against that seed, so the reset does not appear on a track nobody has touched.	TreeSidebarMixin

Methods

Member	Description	Defined by
rpcProps `() => { summaryScoreMode: string; bicolorPivot: number; resolution: number; }`	summaryScoreMode rides along so an adapter can skip work it cannot be asked to show. A store that keeps min/max beside each mean holds three arrays per level, and `avg` — the default — draws none of them, so sending the mode turns the common case back into one read per level instead of three, and drops the two `processFeaturesFromArrays` allocates per source per region for values it then discards. The raw slot, deliberately, and NOT effectiveSummaryScoreMode. The effective one would be tighter -- density resolves whiskers to avg, so it could skip the read there too -- but it changes when the rendering type changes, and anything in rpcProps invalidates the fetch. That would make switching to density discard the data and re-download it, on every multi-wiggle track, including the ones whose adapter gets its summary for free and gains nothing here. Over-fetching in density-with-whiskers is the cheaper mistake. In rpcProps rather than gpuProps because it changes what is fetched: switching the slot to max has to refetch, since a max nobody read cannot be drawn.	MultiLinearWiggleDisplay
gpuProps `() => {…}`	The row list is this display's own: the encoder places each payload source by its position here, so a filter or a reorder re-uploads bytes already in hand.	MultiLinearWiggleDisplay
trackMenuItems `() => MenuItem[]`		MultiLinearWiggleDisplay
contextMenuItems `() => MenuItem[]`	Right-click menu, built from the column the click landed on. The position is captured here rather than read inside the onClick, because `closeContextMenu` runs first when an item is clicked.	MultiLinearWiggleDisplay
renderingProps `() => { displayModel: ModelInstanceTypeProps<{ id: IOptionalIType<…>; type: ISimpleType<string>; }> & { ...; } & { ...; } & { ...; } & IStateTreeNode<...>; }`	props passed to the renderer's React "Rendering" component. these are client-side only and never sent to the worker. includes displayModel and callbacks	BaseDisplay
regionHasData `(_displayedRegionIndex: number) => boolean`	Overridable hook (default true): whether the display can actually draw what this region is marked loaded over. Two different displays want it for two different reasons, and both are real: - The reader-side check of the write-side rule. `loadedRegions` is written where the payload is stored (`RegionFetchContext`), so an entry with nothing behind it means that rule was broken somewhere. Answering off the data map costs a lookup and decides which way the break fails: a refetch, or a viewport that reads as covered against data nobody has and never asks again. Both canvas displays. - Which of several held payloads answers. MAF caches a summary tier and a detail tier side by side under one `displayedRegionIndex`, so crossing the threshold inside an already-loaded region changes which map has to answer — something the coverage bounds cannot see at all. Separate from `regionFetchKey` on purpose: for MAF a key would refetch the summary on every zoom back out, since both tiers are still held. And the mixin cannot see a display's data map, so a key that changed when data arrived would be the `rpcProps()` loop in different clothes. The fail-open default is load-bearing, not an omission. A byte-gate refusal never marks a region loaded (the commit sits beside the store and skips refused results), so "marked loaded with nothing behind it" is unreachable from the gate — the one path that stamps without storing is sequence's legitimately-empty-region answer, and a store-derived default there would refetch forever: stamp, store nothing, read uncovered, fetch again. `true` is what lets "this fetch completed and there is genuinely nothing here" be a terminal state. A view, not an action, for the reason `regionFetchKey` is a getter.	MultiRegionDisplayMixin
isCacheValid `(displayedRegionIndex: number) => boolean`	Whether the data held for a region still answers the current view. Not a hook a display fills: a display states its rule as `regionFetchKey` (what a fetch now would produce) and `regionHasData` (did the last one store anything), and this compares the key against the one the region was fetched under. A subclass that changes what it fetches spells the change in the key, and one that forgets gets a redundant fetch rather than a cached answer for a zoom the data was never fetched at.	MultiRegionDisplayMixin
resolvedByteLimit `() => number \| undefined`	The budget the worker enforces and the banner compares against — the one spelling of that pair. Undefined when the gate may not act.	RegionTooLargeMixin
gateFetchState `() => GateFetchState`	The gate as it stands for a fetch about to be issued. Calling it is the capture, which is why it is a method.	RegionTooLargeMixin
willClearTree `(next: S[]) => boolean`		TreeSidebarMixin

Actions

Member	Description	Defined by
startRenderingBackend `(backend: WiggleRenderingBackend) => void`		MultiLinearWiggleDisplay
setShowRowSeparators `(arg: boolean) => void`		MultiLinearWiggleDisplay
focusLegendGroup `(label: string) => void`	Narrow the rows to the subtracks one color-key row stands for — what clicking that swatch does. A key row is a group where the subtrack has one and the subtrack itself otherwise (`buildLegendItems`), so this matches the same way.	MultiLinearWiggleDisplay
sortRowsByScoreAt `(refName: string, pos: number) => void`	Rank the rows by each source's score at one genomic base. Reads the region data already in hand — no refetch, no RPC — and writes the order through `layout`, the same channel clustering and the arrangement dialog write, so "Reset row order" undoes all three. Named by coordinate rather than by loaded-region index because both entry points are: the right-click hit resolves to one, and a session's `sortRowsBy` carries one across a reload. The region is looked up here, and a position no loaded region covers is left alone rather than sorted against nothing (which would rank every row equally and read as the sort having silently done nothing).	MultiLinearWiggleDisplay
fetchNeeded `(needed: { region: Region; displayedRegionIndex: number; }[]) => Promise<void>`		MultiLinearWiggleDisplay
renderSvg `(opts?: ExportSvgDisplayOptions \| undefined) => Promise<ReactElement<unknown, string \| JSXElementConstructor<any>> \| Iterable<...> \| AwaitedReactNode>`		MultiLinearWiggleDisplay
setStatusMessage `(status?: RpcStatus \| undefined) => void`		BaseDisplay
setError `(error?: unknown) => void`		BaseDisplay
clearHoveredFeature `() => void`	Overridable hook (default no-op): drop whatever `hoveredFeature` reports. The writing twin of that getter, and what `installClearHoverOnViewportChange` calls. A display that STORES its hover owes an override; one that derives it from the live pointer (MAF, Hi-C, LD) owes nothing, and the default costs it nothing. Declared here so the clear can be installed for every display rather than remembered per display — forgetting it is the failure ARCHITECTURE.md's stored-hover section is about, and it used to be six closures at six call sites, which is six chances to omit one.	BaseDisplay
reload `() => void`	base display reload does nothing, see specialized displays for details	BaseDisplay
setScrollTop `(scrollTop: number) => void`	Clamped into `[0, scrollableHeight]`, so no caller has to remember the bound. Unbounded for a display that leaves `scrollableHeight` at its `Infinity` default.	TrackHeightMixin
setHeight `(displayHeight: number) => number`		TrackHeightMixin
resizeHeight `(distance: number) => number`		TrackHeightMixin
expandToContentHeight `() => number`	Grow the track by exactly the content it is currently hiding, so a display scrolled over a taller stack ends up showing all of it. The track's resize handle runs this on a double click. `scrollableHeight` is the whole measurement — it is already every scrolling display's answer to "how much is off the bottom", so no display has to supply a second one. A display that doesn't scroll internally leaves it at `Infinity` and gets a no-op, as does one already showing everything (0). Routed through `resizeHeight` rather than `setHeight` so grow mode's override still gets to leave grow first; going straight to the slot would let the reactive height re-derive `grownHeight` and the double click would appear to do nothing.	TrackHeightMixin
setLoadedRegion `(displayedRegionIndex: number, region: Region, fetchKey?: string) => void`	The raw write behind `ctx.commitRegion`, and not what a fetch should call: a display naming its own span is the bug this family spent a release on, and going through the context is what makes that inexpressible — see RegionFetchContext. Direct callers are tests staging an already-loaded display. An action so callers after an async boundary stay in MST strict mode. Stamps the region with the fetch key its data came back under. `fetchRegions` passes the key it captured before issuing the RPC; the default reads it now, which is right for a caller holding the region already and wrong for anything resuming after an await, where the viewport may have moved under the fetch.	MultiRegionDisplayMixin
dropLoadedRegion `(displayedRegionIndex: number) => void`	Forget one region — for a display pruning what has scrolled off screen.	MultiRegionDisplayMixin
clearDisplaySpecificData `() => void`	no-op base — subclasses override to clear rpcDataMap etc.	MultiRegionDisplayMixin
clearAllRpcData `() => void`	full reset: cancels fetch, clears error, loadedRegions, display-specific data, and the canvas-drawn flag. The too-large gate is derived (a pure function of the cached estimate × viewport), so it needs no explicit clear here — the fetch autorun re-measures at the new viewport and the verdict follows.	MultiRegionDisplayMixin
fetchRegions `(needed: IndexedRegion[], work: (ctx: RegionFetchContext) => Promise<void>) => Promise<void>`	Run a per-region fetch. The work callback calls `ctx.commitRegion` as it stores each region's payload, which is what marks it loaded — see RegionFetchContext for why this function no longer does that itself. Its only callers are the three helpers in `fetchEachRegion.ts`, which make that call for every display in the family; a display reaching past them owns both `ctx.isStale()` guards and the commit by hand, and none does. The fetch key is captured here, at issue, and carried into every commit — never re-read after the await. `ctx.isStale()` trips on a newer fetch or a cancel, not on a viewport that moved under a fetch that is still current, so a key read at commit time would stamp this data with a zoom it was not fetched at.	MultiRegionDisplayMixin
afterAttach `() => void`	installs the fetch-lifecycle autoruns (DisplayedRegionsChange, FetchVisibleRegions, SettingsInvalidate, ClearBlockingStateOnViewportChange)	MultiRegionDisplayMixin
setByteEstimate `(measurement: { bytes: number; viewport: GateViewport; }) => void`	The bytes half of a measurement alone, for a test staging a display. Production commits through `commitFetchBytes`.	RegionTooLargeMixin
clearByteEstimate `() => void`	Drops the estimate and the viewport stamp. `forceLoadTrack` survives: it is a track-wide approval.	RegionTooLargeMixin
setForceLoadTrack `(flag: boolean) => void`		RegionTooLargeMixin
commitFetchBytes `(perRegionBytes: (number \| undefined)[], issued: GateFetchState) => void`	The byte axis of a finished fetch, called by the fetch runners with the `gateFetchState()` they captured at issue. Commits the per-region max; an empty batch, or an ungated display, commits nothing.	RegionTooLargeMixin
forceLoad `() => void`	The banner's button: exempt the track on both axes and refetch.	RegionTooLargeMixin
markCanvasDrawn `() => void`		RenderLifecycleMixin
resetCanvasDrawn `() => void`		RenderLifecycleMixin
stopRenderingBackend `() => void`		RenderLifecycleMixin
renderNow `() => void`		RenderLifecycleMixin
setRenderError `(error: unknown) => void`	set/clear the render-backend error. Called by `useRenderingBackend`: with the error when the canvas factory rejects (or context-loss re-init fails), and with `undefined` on successful (re)init and on retry.	RenderLifecycleMixin
attachRenderingBackend `<B>(backend: B, setup: () => RenderingBackendCallbacks<B>) => void`	attach a GPU/Canvas2D backend and install the upload + render autorun pair. Idempotent: re-calling swaps the backend and does not run `setup` again, so the callbacks and everything they close over are the first call's.	RenderLifecycleMixin
stopActiveFetch `() => void`	Abort the in-flight fetch (if any) and retire its slot. The shared preamble of both cancel paths; the difference between them is only what they do to `fetchCanceled` / `fetchGeneration` afterward.	FetchMixin
openStatusStream `(isCurrent: () => boolean) => StatusStream`	Open one operation's slot on the display's status field: an RPC `statusCallback` throttled through the display-wide window and guarded so a callback that fires after the node is torn down (RPCs resolve their status stream asynchronously) is a safe no-op, plus the `clear` that retires the slot when the operation ends. Every operation on the display opens one, and the two come back together because an operation that never retires goes on voting for a phase that is over. The viewport fetch (`runFetch`), the clustering run and a lent `createStopTokenRotation` are three of them on one field; before ADR-081 each blanked the field outright and the last one to finish decided what the other two were still saying. `isCurrent` is required and has no "node is alive" default, because alive is not the interesting question: a superseded fetch is on a live node, and its late status repainting the overlay of the fetch that replaced it is the failure this guards. `runFetch` passes `!isStale()`, which is what every display gets for free through `ctx.statusCallback`; a caller outside a fetch (the clustering autorun) passes its own run's flag. Defaulting to `isAlive` made the loose answer the easy one and five displays took it. Declared this early only so `runFetch` can put one on every `FetchContext`.	FetchMixin
cancelFetch `() => void`	cancel any in-flight fetch and bump fetchGeneration (always bumps, so callers can retrigger fetch autoruns even when nothing was in flight). This is the internal reset `clearAllRpcData` runs — it clears any user-cancel flag so the retrigger actually re-fetches.	FetchMixin
cancelFetchByUser `() => void`	User-initiated cancel from the loading overlay. Stops the in-flight fetch and lands in a durable `fetchCanceled` state. Unlike `cancelFetch`, it does NOT bump fetchGeneration — so the fetch autoruns don't immediately restart the load. The user retries via `reload` (the overlay's retry button), or it clears on the next viewport change.	FetchMixin
beforeDestroy `() => void`	Release an in-flight fetch's stop token on teardown. Without this, a display destroyed mid-fetch (track/view closed while loading) never signals the worker to abort the now-useless work, and its in-flight HTTP reads keep downloading. MST auto-chains lifecycle hooks, so a composing display can still define its own beforeDestroy.	FetchMixin
endFetch `(current: boolean, stopToken: StopToken) => void`	The `finally` half of `runFetch`'s bookkeeping, an action of its own because `runFetchOnce`'s `finally` resumes on a microtask the flow does not own — a direct volatile write there is outside the action context, which is the one thing hoisting the sequence into a shared function costs. The stale branch is a superseded fetch: whoever superseded it — a newer `begin`, or `cancel` — already released this token.	FetchMixin
runFetch `(work: (ctx: FetchContext) => Promise<void>) => Promise<void>`	Run a cancel-safe fetch (cancels any prior). The work callback gets a FetchContext with a stopToken to forward to the RPC and an isStale() check to short-circuit commits once the user has moved on. The MST-flow wrapper over the shared `runFetchOnce` sequence, and only the wrapper: the begin/clear/run/commit/error/end order, and the rules that keep a superseded run from writing back, are the same function every other fetch in the tree runs. What this adds is the observable bookkeeping a display needs — `isLoading` through `activeStopToken`, `fetchGeneration`, the user-cancel clear — and the flow itself, which is an action, so `work`'s synchronous prefix runs untracked wherever a fetch autorun calls this.	FetchMixin
setRpcData `(displayedRegionIndex: number, data: WiggleDataResult) => void`	The store half of both displays' `fetchNeeded`. Everything either one derives from a fetch — multi-wiggle's row list included — is a getter over this map, so there is nothing else for a result to update.	WiggleCommonMixin
setHoveredFeature `(feat?: WiggleHoveredFeature \| undefined) => void`		WiggleCommonMixin
selectFeature `(feat: WiggleHoveredFeature) => void`		WiggleCommonMixin
setResolution `(res: number) => void`		WiggleCommonMixin
setBicolorPivot `(val?: number \| undefined) => void`		WiggleCommonMixin
setPosColor `(color?: string \| undefined) => void`	Lives here beside the `posColor`/`negColor` getters and `setBicolorPivot` so both the single- and multi-wiggle color editors write the score-sign palette the same way.	WiggleCommonMixin
setNegColor `(color?: string \| undefined) => void`		WiggleCommonMixin
setRenderingType `(type: string) => void`		WiggleCommonMixin
setSummaryScoreMode `(val: string) => void`		WiggleCommonMixin
setLineWidth `(val?: number \| undefined) => void`		WiggleCommonMixin
toggleCrossHatches `() => void`		WiggleScoreConfigMixin
setScatterPointSize `(val?: number \| undefined) => void`		WiggleScoreConfigMixin
setScaleType `(scaleType: string) => void`		ScoreScaleMixin
setAutoscale `(val?: string \| undefined) => void`		ScoreScaleMixin
setMinScore `(val?: number \| undefined) => void`		ScoreScaleMixin
setMaxScore `(val?: number \| undefined) => void`		ScoreScaleMixin
setShowLegend `(arg: boolean) => void`		LegendMixin
setShowTree `(arg: boolean) => void`		TreeSidebarMixin
setShowBranchLength `(arg: boolean) => void`		TreeSidebarMixin
setShowRowLabels `(arg: boolean) => void`		TreeSidebarMixin
setLayout `(layout: S[]) => void`		TreeSidebarMixin
clearLayout `() => void`		TreeSidebarMixin
setClusterTree `(tree?: string \| undefined) => void`		TreeSidebarMixin
setLayoutAndClusterTree `(layout: S[], tree?: string \| undefined, provenance?: ClusterProvenance \| undefined) => void`		TreeSidebarMixin
setTreeAreaWidth `(width: number) => void`		TreeSidebarMixin
setSubtreeFilter `(names?: string[] \| undefined) => void`		TreeSidebarMixin
setRunClustering `(arg?: boolean \| undefined) => void`		TreeSidebarMixin
setClusterRegion `(arg?: string \| undefined) => void`		TreeSidebarMixin
setSortRowsBy `(arg?: RowSortSpec \| undefined) => void`	Trigger (or clear) a one-shot declarative row sort; consumed and reset by `setupRowSortAutorun`. A display's right-click item calls its own sort directly (instant, the data is already loaded); this is the session-level entry point.	TreeSidebarMixin
setHoveredTreeNode `(node?: HoveredTreeNode \| undefined) => void`		TreeSidebarMixin
setTreeCanvasRef `(ref: HTMLCanvasElement \| null) => void`		TreeSidebarMixin
setMouseoverCanvasRef `(ref: HTMLCanvasElement \| null) => void`		TreeSidebarMixin
openContextMenu `(info: Info) => void`		ContextMenuMixin
closeContextMenu `() => void`		ContextMenuMixin

Guide: Multi-quantitative track
Guide: Single-cell ATAC pseudobulk

MultiLinearWiggleDisplay

Example usage#

Properties#

Volatiles#

Getters#

Methods#

Actions#

Related links#