# DotplotDisplay

Auto-generated @jbrowse/mobx-state-tree API for the current JBrowse release —
see [pluggable elements](https://jbrowse.org/jb2-staging/docs/developer_guide/) for concepts. Provided by the
`dotplot-view` plugin.
[View source](https://github.com/GMOD/jbrowse-components/blob/main/plugins/dotplot-view/src/DotplotDisplay/stateModelFactory.tsx).

The configuration slots for this model are documented on its
[config schema page](../../config/dotplotdisplay).

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

## Properties

<!-- prettier-ignore -->
| Member | Description | Defined by |
| --- | --- | --- |
| <span id="property-type">**type**</span><br><code>type: types.literal('DotplotDisplay')</code> |  | DotplotDisplay |
| <span id="property-configuration">**configuration**</span><br><code>configuration: ConfigurationReference(configSchema)</code> |  | DotplotDisplay |
| <span id="property-id">**id**</span><br><code>id: ElementId</code> |  | [BaseDisplay](../basedisplay#property-id) |

## Volatiles

<!-- prettier-ignore -->
| Member | Description | Defined by |
| --- | --- | --- |
| <span id="volatile-rpcdata">**rpcData**</span><br><code>rpcData: undefined as DotplotRpcData &#124; undefined</code> | RPC-computed feature data | DotplotDisplay |
| <span id="volatile-instancedata">**instanceData**</span><br><code>instanceData: undefined as DotplotInstanceData &#124; undefined</code> | GPU-instance positions produced from rpcData, self-describing via embedded bpPerPx, with no colors in them. Rebuilt only when the data or the zoom changes; the palette is joined on top by the `geometry` getter. | DotplotDisplay |
| <span id="volatile-fetchwarnings">**fetchWarnings**</span><br><code>fetchWarnings: [] as ComparativeWarning[]</code> | What the last completed fetch had to say about itself, written with the data it describes (see `setRpcData`). | DotplotDisplay |
| <span id="volatile-hoveredsegmentidx">**hoveredSegmentIdx**</span><br><code>hoveredSegmentIdx: -1</code> | Index into `instanceData`'s per-SEGMENT arrays of the line the pointer is nearest, or -1.<br><br>The segment rather than the feature, even though the tooltip and the highlight are both about the feature: the feature index derives from this one (`hoveredFeatureIdx` below), and the CIGAR operator under the cursor derives from nothing else — a CIGAR-detailed alignment is a staircase of segments and the pointer is on one step of it. Same choice `LinearSyntenyDisplay.hoveredInstanceIdx` makes, where `getFeature` does the translating.<br><br>It addresses `instanceData`, so it is dropped by BOTH writers of that — a zoom rebuilds the geometry without refetching. | DotplotDisplay |
| <span id="volatile-error">**error**</span><br><code>error: undefined as unknown</code> |  | [BaseDisplay](../basedisplay#volatile-error) |
| <span id="volatile-statusmessage">**statusMessage**</span><br><code>statusMessage: undefined as string &#124; undefined</code> |  | [BaseDisplay](../basedisplay#volatile-statusmessage) |
| <span id="volatile-statusprogress">**statusProgress**</span><br><code>statusProgress: undefined as number &#124; undefined</code> | <span data-pagefind-ignore>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.</span> | [BaseDisplay](../basedisplay#volatile-statusprogress) |
| <span id="volatile-fetching">**fetching**</span><br><code>fetching: false</code> | <span data-pagefind-ignore>True while an RPC fetch is in-flight. Combined with `ready` it distinguishes a first load (no data yet — full overlay) from a refetch (stale content still on screen — corner indicator).</span> | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#volatile-fetching) |
| <span id="volatile-loadedfetchkey">**loadedFetchKey**</span><br><code>loadedFetchKey: undefined as string &#124; undefined</code> | <span data-pagefind-ignore>Fetch-input signature the currently held data was fetched for (each display builds its own `currentFetchKey`). Compared against the live inputs in `dataCurrent` to catch data gone stale after a region/zoom change — including during the pre-refetch debounce gap, where `fetching` is still false and would otherwise report done on content drawn against the old viewport.</span> | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#volatile-loadedfetchkey) |
| <span id="volatile-assembliesswapped">**assembliesSwapped**</span><br><code>assembliesSwapped: false</code> | <span data-pagefind-ignore>Set once at view load by a refName-comparison check, independent of the per-render fetch, so it never re-fires or misfires on zoom. Surfaces through each display's `warnings`.</span> | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#volatile-assembliesswapped) |
| <span id="volatile-reloadcounter">**reloadCounter**</span><br><code>reloadCounter: 0</code> | <span data-pagefind-ignore>Bumped by `reload()`. Read unconditionally by `installComparativeFetchAutorun`, so it is always in the autorun's dependency set — which is the whole point: after an error the fetch inputs are unchanged, so nothing else would ever refire the autorun and the error banner's Retry would be a button that does nothing.</span> | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#volatile-reloadcounter) |
| <span id="volatile-fetchcanceled">**fetchCanceled**</span><br><code>fetchCanceled: false</code> | <span data-pagefind-ignore>True from the moment the user clicks Cancel on the loading overlay (`cancelFetchByUser`) until `reload()` clears it. Durable and blocking: `installComparativeFetchAutorun` gates on it, so nothing restarts the load in the meantime — not a zoom, not a region change, and no timer.<br><br>That is the deliberate half. These displays sit on single RPCs that can run for minutes against a remote index, so a cancel any pan quietly undoes is not a cancel, and a retry that re-arms itself hammers the server that just failed. The way back is the overlay's Retry button and nothing else — `LoadingOverlay` draws it off this flag.</span> | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#volatile-fetchcanceled) |
| <span id="volatile-stopactivefetch">**stopActiveFetch**</span><br><code>stopActiveFetch: () =&gt; {}</code> | <span data-pagefind-ignore>Stops the in-flight RPC. `installComparativeFetchAutorun` hands over its stop-token rotation's `cancel` at install (`setStopActiveFetch`): the rotation lives in that skeleton's closure, one per install and beside the fetch that uses it, and this mixin holds no fetch machinery of its own (ADR-054).<br><br>**A cancel that cannot reach it is not a cancel.** Nothing else rotates the token, so the run the user stopped watching stays `isCurrent()` and COMMITS its result when it lands — the plot appears, the overlay disappears, and the cancel is undone by the fetch it cancelled. Stopping the token is also the only thing that tells the worker to drop the reads still in flight, which is half of why a user clicks it.<br><br>A no-op until the skeleton installs, so a display with no fetch autorun can still be asked.</span> | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#volatile-stopactivefetch) |

## Getters

<!-- prettier-ignore -->
| Member | Description | Defined by |
| --- | --- | --- |
| <span id="getter-view">**view**</span><br><code>DotplotViewModel</code> | The plot this display draws into. One getter rather than a `getContainingView` cast per reader, the same way `LinearSyntenyDisplay.view` answers it.<br><br>This names the view type even though the view names this display back (`dotplotDisplays`). That mutual reference resolves only because both model types are declared as `interface … extends Instance<…>` rather than `type … = Instance<…>` — see ADR-055. | DotplotDisplay |
| <span id="getter-displaykey">**displayKey**</span><br><code>number</code> | Stable slot on the view-shared backend. Hashed from the node id, not taken from the track's index, so hiding or reordering a sibling can't hand this display another's buffer. | DotplotDisplay |
| <span id="getter-ready">**ready**</span><br><code>boolean</code> | A fetch has completed (data is present, even if it mapped zero features). Not a feature-count test — an empty-but-finished fetch is ready, otherwise an empty plot spins the loading overlay forever. | DotplotDisplay |
| <span id="getter-computedcolors">**computedColors**</span><br><code>Uint32Array&lt;ArrayBufferLike&gt; &#124; undefined</code> | Main-thread-computed per-segment colors — the gpuProps half of the rpcProps/gpuProps split. A colorBy change recomputes this alone, without re-walking a single CIGAR.<br><br>Opacity is NOT read here. It rides the shader's `alpha` uniform (and `drawDotplotInstances`' param) off `DotplotView.dotplotRenderState`, so the slider is a redraw, not a recolor — the same split synteny makes. Baking it in made every drag frame recompute this array, re-pack every instance and re-upload the buffer. | DotplotDisplay |
| <span id="getter-paintedchromosomeorder">**paintedChromosomeOrder**</span><br><code>readonly string[] &#124; undefined</code> | The chromosome order the chromosome-painting modes color by: the refNames of whichever axis' assembly `colorBy` names, in the assembly's own order. Undefined for every other mode, and while the assembly is still loading — the color function falls back to its hash there.<br><br>It has to come from the assembly rather than from the features, because a color must not change with which chromosomes happen to be in view.<br><br>The dotplot twin of `LinearSyntenyDisplay.paintedChromosomeOrder`, off the two axes instead of two stacked levels: 'query' is the horizontal axis (the feature's own refName lane) and 'target' the vertical (the mate's). 'reference' is a stacked-view mode with no dotplot meaning, and the shared color function falls it back to query — with no order, since naming an axis for it would be inventing an answer. | DotplotDisplay |
| <span id="getter-colorby">**colorBy**</span><br><code>SyntenyColorBy</code> | The mode this track renders with: its own override if the user set one, else the plot-wide mode. | DotplotDisplay |
| <span id="getter-trackcolor">**trackColor**</span><br><code>string</code> | This track's slot in the plot's palette, used by `colorBy: 'track'`. Assigned by the view, not locally: pinning a color on one track shifts which automatic slots its siblings can take. | DotplotDisplay |
| <span id="getter-trackid">**trackId**</span><br><code>string</code> |  | DotplotDisplay |
| <span id="getter-geometry">**geometry**</span><br><span class="cell-more"><button type="button" class="cell-more-trigger"><code>{ colors: Uint32Array&lt;ArrayBufferLike&gt;; x1: Float64Array&lt;ArrayB…</code></button><dialog class="cell-dialog"><form method="dialog"><button class="cell-dialog-close" aria-label="Close">✕</button></form><pre><code>{ colors: Uint32Array&lt;ArrayBufferLike&gt;; x1: Float64Array&lt;ArrayBufferLike&gt;; y1: Float64Array&lt;ArrayBufferLike&gt;; ... 6 more ...; baseV: number; } &#124; undefined</code></pre></dialog></span> | Instance positions joined with the computed colors: what the backends upload and what SVG export draws. The view's upload autorun reads this, so a palette change re-uploads without rebuilding geometry. | DotplotDisplay |
| <span id="getter-hoveredfeatureidx">**hoveredFeatureIdx**</span><br><code>number</code> | Index into `rpcData`'s per-FEATURE arrays of the alignment the pointer is over, or -1. Derived rather than stored, so it cannot disagree with `hoveredSegmentIdx` about which alignment that is.<br><br>Not `instanceFeatureIdx[i] ?? i`: an out-of-range segment index reads `undefined` there, and falling back to the raw index would answer with a different feature rather than with nothing. Same reasoning as `LinearSyntenyDisplay.getFeature`. | DotplotDisplay |
| <span id="getter-tooltiplines">**tooltipLines**</span><br><code>string[] &#124; undefined</code> | The hovered feature's tooltip, as lines, or undefined when nothing is hovered. The dotplot twin of `LinearSyntenyDisplay.tooltipLines`; both feed `ComparativeTooltip`, which renders lines as text nodes — see `getDotplotTooltipLines`. | DotplotDisplay |
| <span id="getter-hoveredfeaturehighlight">**hoveredFeatureHighlight**</span><br><code>DotplotHoverHighlight &#124; undefined</code> | The hovered feature redrawn over the canvas: an SVG path of its segments in plot px, plus its own packed color as CSS.<br><br>This is the whole of the hover shading, and it deliberately isn't in either renderer. Synteny boosts alpha and darkens rgb per fragment from a `hoveredFeatureId` uniform, which costs an instance lane, a uniform, a hand-written Canvas2D twin of the same arithmetic, and a broken color run in `drawDotplotInstances`' batcher. Restroking one feature — a handful of segments — over the shared canvas needs none of that, and is backend-agnostic by construction: it draws the same over the GPU canvas and the Canvas2D fallback because it never asks which one painted. `renderSvg` deliberately does not draw it — an off-screen export has no pointer, and a transient hover has no business in a figure.<br><br>The cue is opacity + width, not hue: the plot's own `alpha` slider routinely sits at 0.2, so restroking opaque and a few px wider is exactly synteny's "the hovered one goes solid". Nothing here picks a highlight color, because every hue is already in use — category10 paints the chromosome modes, and red/blue/black are the strand and default schemes.<br><br>Recomputes on pan (through `plotTransform`'s `viewBpH`/`viewBpV`), which is what keeps the highlight on its feature, and only while something is hovered. `plotTransform` rather than `dotplotRenderState`, which carries `alpha` and `lineWidth` too — an opacity drag would rebuild this path once a frame for a value it does not read. | DotplotDisplay |
| <span id="getter-fetchflags">**fetchFlags**</span><br><code>ComparativeFetchFlags</code> |  | DotplotDisplay |
| <span id="getter-loading">**loading**</span><br><code>boolean</code> | First load: no data has arrived yet. Drives the centered overlay. | DotplotDisplay |
| <span id="getter-refetching">**refetching**</span><br><code>boolean</code> | Refetch in-flight: a new fetch is running but a stale plot is still on screen (zoom, diagonalize reorder, pan past the buffer). Drives a subtle corner indicator instead of the full overlay so the visible plot isn't masked on every viewport change. | DotplotDisplay |
| <span id="getter-fetchregions">**fetchRegions**</span><br><code>Region[]</code> | The h-axis fetch window: the visible content blocks expanded by the shared pan buffer and snapped outward to a buffer-sized grid, so a pan within the buffer neither refetches nor exposes an unfetched strip, and zoomed out it collapses to the whole displayed region. The v axis is deliberately not scoped: the fetch is one-dimensional (h regions in, every mate out), so a vertical pan needs no data the h window didn't already bring, and must never trigger a refetch.<br><br>Unlike synteny, nothing culls this window again in the worker — executeDotplotFeaturesAndPositions maps every feature it is handed — so the window's only job is to be a superset of what's on screen. | DotplotDisplay |
| <span id="getter-currentfetchkey">**currentFetchKey**</span><br><code>string</code> | The fetch-input signature (see fetchKey.ts) for the view's current state. Reactive: recomputes when either axis's zoom or displayed-region order/orientation changes, or when a pan carries the h axis into a new snapped fetch window. As a computed it only notifies when the string itself changes, which is what lets the fetch autorun track it and stay quiet through sub-buffer pans. | DotplotDisplay |
| <span id="getter-lodtier">**lodTier**</span><br><code>LodTier</code> | The detail tier this plot's fetch asks the adapter for. Resolved here on the main thread, not adapter-side from `bpPerPx`, so it is part of `currentFetchKey` — see `resolveLodTier`. Both axes feed it: CIGAR detail is worth drawing when a block is wide on either one, so dropping to the no-CIGAR tier is only safe once both are past the threshold. | DotplotDisplay |
| <span id="getter-datacurrent">**dataCurrent**</span><br><code>boolean</code> | True when the rendered rpcData was fetched for the view's current inputs. Goes false the instant a zoom or diagonalize reorder changes the axes — before the debounced refetch begins and while stale geometry is still on screen — so the `settled` done-gate can't fire on it. The dotplot analog of LGV's `viewportWithinLoadedData`. | DotplotDisplay |
| <span id="getter-displayphase">**displayPhase**</span><br><code>DisplayStatusPhase</code> | The display's own mutually-exclusive state, the way every LGV display publishes one — so `AppReadyMarker` counts this display's fetch, and the app stops reporting itself ready over a plot that is still working. Ranked by `comparativeDisplayPhase`, off the shared canvas's `surfaceReadiness` and this display's own fetch state.<br><br>`DisplayStatusPhase`, not `DisplayPhase`: the view owns the rendering backend, so this display can never be the one to report a backend failure. | DotplotDisplay |
| <span id="getter-warnings">**warnings**</span><br><code>ComparativeWarning[]</code> | Per-render fetch warnings, plus the load-time reversed-assembly hint. | DotplotDisplay |
| <span id="getter-svgready">**svgReady**</span><br><code>boolean</code> | Off-screen SVG export gate: "Export SVG" waits on this before drawing (see the [SVG export guide](https://jbrowse.org/jb2-staging/docs/developer_guides/svg_export)). Runs the same shared `computeSvgReady` policy every other display does and awaits it via the shared `awaitSvgReady` — no inlined `when()`. A failed track fails the export rather than drawing itself into the plot; every display paints that one rect, so `SVGDotplotView` fans them out through `awaitSvgRenders` and names all of them at once. No `regionTooLarge` state: the fetch is gated by LOD, not region size. Stale-safe via `dataCurrent`: an export fired right after a zoom/diagonalize reorder waits for geometry rebuilt from the fresh fetch instead of exporting the stale plot. | DotplotDisplay |
| <span id="getter-parenttrack">**parentTrack**</span><br><code>AbstractTrackModel</code> |  | [BaseDisplay](../basedisplay#getter-parenttrack) |
| <span id="getter-renderingcomponent">**RenderingComponent**</span><br><code>FC&lt;…&gt;</code> |  | [BaseDisplay](../basedisplay#getter-renderingcomponent) |
| <span id="getter-displayblurb">**DisplayBlurb**</span><br><span class="cell-more"><button type="button" class="cell-more-trigger"><code>FC&lt;{ model: ModelInstanceTypeProps&lt;{ id: IOptionalIType&lt;ISimple…</code></button><dialog class="cell-dialog"><form method="dialog"><button class="cell-dialog-close" aria-label="Close">✕</button></form><pre><code>FC&lt;{ model: ModelInstanceTypeProps&lt;{ id: IOptionalIType&lt;ISimpleType&lt;string&gt;, [undefined]&gt;; type: ISimpleType&lt;string&gt;; }&gt; &amp; { ...; } &amp; { ...; } &amp; IStateTreeNode&lt;...&gt;; }&gt; &#124; null</code></pre></dialog></span> |  | [BaseDisplay](../basedisplay#getter-displayblurb) |
| <span id="getter-adapterconfig">**adapterConfig**</span><br><code>Record&lt;string, unknown&gt;</code> |  | [BaseDisplay](../basedisplay#getter-adapterconfig) |
| <span id="getter-isminimized">**isMinimized**</span><br><code>boolean</code> | <span data-pagefind-ignore>Returns true if the parent track is minimized. Used to skip expensive operations like autoruns when track is not visible.</span> | [BaseDisplay](../basedisplay#getter-isminimized) |
| <span id="getter-hoveredfeature">**hoveredFeature**</span><br><code>unknown</code> | <span data-pagefind-ignore>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.<br><br>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.<br><br>`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.</span> | [BaseDisplay](../basedisplay#getter-hoveredfeature) |
| <span id="getter-featurenoun">**featureNoun**</span><br><code>string</code> | <span data-pagefind-ignore>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".<br><br>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.<br><br>**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.<br><br>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.</span> | [BaseDisplay](../basedisplay#getter-featurenoun) |
| <span id="getter-featurewidgettype">**featureWidgetType**</span><br><code>{ type: string; id: string; }</code> | <span data-pagefind-ignore>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.<br><br>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.</span> | [BaseDisplay](../basedisplay#getter-featurewidgettype) |
| <span id="getter-fetchinert">**fetchInert**</span><br><code>boolean</code> | <span data-pagefind-ignore>Overridable hook, default false: the states where this display's fetch autorun deliberately never runs, so it holds no data and none is coming. Anything waiting on data has to treat those as terminal rather than wait forever — which is why the answer lives in one place and is read by the autorun's own gate, the loading overlay, the SVG export's `extraTerminal`, and `displaysSettled` below.<br><br>`displaysSettled` is the reason this is a mixin hook rather than a display-local getter: it is the one reader outside the display, and without the hook it demanded `dataCurrent` from a display whose `loadedFetchKey` can never be set — wedging the view's `settled` gate, and with it the `data-display-drawn` screenshot capture waits on.<br><br>Default false is the strict answer, so a display that grows an inert state and forgets to say so keeps waiting for data (diagnosable) rather than reporting done without it (silently wrong). Dotplot leaves it: its `prepare` bails only before the view is initialized, which the view's own `canvasDrawn`/`canRender` gate already covers.</span> | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#getter-fetchinert) |

## Methods

<!-- prettier-ignore -->
| Member | Description | Defined by |
| --- | --- | --- |
| <span id="method-rendersvg">**renderSvg**</span><br><span class="cell-more"><button type="button" class="cell-more-trigger"><code>(opts: ExportSvgOptions &amp; { theme?: ThemeOptions &#124; undefined; }…</code></button><dialog class="cell-dialog"><form method="dialog"><button class="cell-dialog-close" aria-label="Close">✕</button></form><pre><code>(opts: ExportSvgOptions &amp; { theme?: ThemeOptions &#124; undefined; }) =&gt; Promise&lt;Element &#124; null&gt;</code></pre></dialog></span> |  | DotplotDisplay |
| <span id="method-renderingprops">**renderingProps**</span><br><span class="cell-more"><button type="button" class="cell-more-trigger"><code>() =&gt; { displayModel: ModelInstanceTypeProps&lt;{ id: IOptionalITy…</code></button><dialog class="cell-dialog"><form method="dialog"><button class="cell-dialog-close" aria-label="Close">✕</button></form><pre><code>() =&gt; { displayModel: ModelInstanceTypeProps&lt;{ id: IOptionalIType&lt;…&gt;; type: ISimpleType&lt;string&gt;; }&gt; &amp; { ...; } &amp; { ...; } &amp; { ...; } &amp; IStateTreeNode&lt;...&gt;; }</code></pre></dialog></span> | <span data-pagefind-ignore>props passed to the renderer's React "Rendering" component. these are client-side only and never sent to the worker. includes displayModel and callbacks</span> | [BaseDisplay](../basedisplay#method-renderingprops) |
| <span id="method-trackmenuitems">**trackMenuItems**</span><br><code>() =&gt; MenuItem[]</code> |  | [BaseDisplay](../basedisplay#method-trackmenuitems) |

## Actions

<!-- prettier-ignore -->
| Member | Description | Defined by |
| --- | --- | --- |
| <span id="action-setrpcdata">**setRpcData**</span><br><span class="cell-more"><button type="button" class="cell-more-trigger"><code>(data: DotplotRpcData, fetchKey: string, warnings: ComparativeW…</code></button><dialog class="cell-dialog"><form method="dialog"><button class="cell-dialog-close" aria-label="Close">✕</button></form><pre><code>(data: DotplotRpcData, fetchKey: string, warnings: ComparativeWarning[]) =&gt; void</code></pre></dialog></span> | Commits a fetch result and the warnings it raised, tagged with the key it was fetched for. One action, not three: the warnings describe this result, so writing them separately let a failed refetch leave the last result's warnings standing over data they no longer describe, and each extra action is another round of the view's warning/upload observers per RPC completion. Same reason `LinearSyntenyDisplay.setRpcData` takes its feature and instance data together.<br><br>The loading flags are deliberately NOT touched here: this runs as `installComparativeFetchAutorun`'s `commit`, whose `finally` clears `fetching` and the status line under the same staleness guard. Clearing them here too meant one of the two comparative displays wrote `fetching` directly instead of through `setFetching`, for no effect the skeleton wasn't about to have anyway.<br><br>`setError` is not overridden either: the two callers that set one (the fetch skeleton's `catch`, `afterAttach`'s) already log it, so the override this display used to carry printed every fetch failure twice — and had to special-case `undefined` because the skeleton clears the error through the same setter before every fetch. | DotplotDisplay |
| <span id="action-setinstancedata">**setInstanceData**</span><br><code>(data: DotplotInstanceData &#124; undefined) =&gt; void</code> |  | DotplotDisplay |
| <span id="action-sethoveredsegmentidx">**setHoveredSegmentIdx**</span><br><code>(idx: number) =&gt; void</code> | Written by the view's `setHoveredFeature`, which points the whole plot's hover at one hit — never per display from a component, so the N writes land in one MobX batch. | DotplotDisplay |
| <span id="action-setstatusmessage">**setStatusMessage**</span><br><code>(status?: RpcStatus &#124; undefined) =&gt; void</code> |  | [BaseDisplay](../basedisplay#action-setstatusmessage) |
| <span id="action-seterror">**setError**</span><br><code>(error?: unknown) =&gt; void</code> |  | [BaseDisplay](../basedisplay#action-seterror) |
| <span id="action-clearhoveredfeature">**clearHoveredFeature**</span><br><code>() =&gt; void</code> | <span data-pagefind-ignore>Overridable hook (default no-op): drop whatever `hoveredFeature` reports. The writing twin of that getter, and what `installClearHoverOnViewportChange` calls.<br><br>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.</span> | [BaseDisplay](../basedisplay#action-clearhoveredfeature) |
| <span id="action-reload">**reload**</span><br><code>() =&gt; void</code> | <span data-pagefind-ignore>base display reload does nothing, see specialized displays for details</span> | [BaseDisplay](../basedisplay#action-reload) |
| <span id="action-setfetching">**setFetching**</span><br><code>(arg: boolean) =&gt; void</code> |  | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#action-setfetching) |
| <span id="action-setassembliesswapped">**setAssembliesSwapped**</span><br><code>(arg: boolean) =&gt; void</code> |  | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#action-setassembliesswapped) |
| <span id="action-setstopactivefetch">**setStopActiveFetch**</span><br><code>(stop: () =&gt; void) =&gt; void</code> | <span data-pagefind-ignore>Install-time wiring, called once by `installComparativeFetchAutorun` — see `stopActiveFetch` for why the stop arrives from there rather than being built here.</span> | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#action-setstopactivefetch) |
| <span id="action-cancelfetchbyuser">**cancelFetchByUser**</span><br><code>() =&gt; void</code> | <span data-pagefind-ignore>The loading overlay's Cancel. Stops the in-flight RPC and lands in the durable `fetchCanceled` state, so the fetch autorun's gate holds until `reload()` reopens it.<br><br>Same name as `FetchMixin`'s, which is what lets one overlay set serve all three fetch families (`DisplayLoadingOverlayModel` names it). What has no twin here is the *internal* half of that split, `cancelFetch` — stop, clear the flag, bump a generation to retrigger — because it exists there for `clearAllRpcData`, and this family has nothing that resets a display behind the user's back. `reload()` is the only thing that reopens the gate, which is exactly the constraint: retry is a button, never an automatic re-arm.<br><br>Clears `fetching` itself, because nothing else will: the in-flight run's `finally` writes it only while `isCurrent()`, and the stop above just closed that guard.</span> | [SyntenyFetchStateMixin](../syntenyfetchstatemixin#action-cancelfetchbyuser) |