ChordVariantDisplay

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

Example usage

The circular-view display for a VariantTrack of structural variants; translocations are drawn as chords across the circle. The track config below is what creates it; its colors are the config slots on ChordVariantDisplay:

{
  type: 'VariantTrack',
  trackId: 'sv',
  name: 'Structural variants',
  assemblyNames: ['hg38'],
  adapter: {
    type: 'VcfTabixAdapter',
    uri: 'https://example.com/sv.vcf.gz',
  },
  displays: [
    {
      type: 'ChordVariantDisplay',
      displayId: 'sv-ChordVariantDisplay',
    },
  ],
}

bezierRadiusRatio below is a property of this model rather than a config slot: it sets the deepest bow toward the center, which a chord straight across the circle reaches, and a shorter-range one bows in proportion to its span. Nothing in the UI sets it and a track config drops it, so today only a hand-edited session carries a value other than the default.

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('ChordVariantDisplay')`		ChordVariantDisplay
bezierRadiusRatio `bezierRadiusRatio: types.stripDefault(types.number, 0.1)`		ChordVariantDisplay
configuration `configuration: ConfigurationReference(configSchema)`		ChordVariantDisplay
id `id: ElementId`		BaseDisplay

Volatiles

Member	Description	Defined by
features `features: undefined as Feature[] \| undefined`		ChordVariantDisplay
refNameMap `refNameMap: undefined as Record<string, string> \| undefined`		ChordVariantDisplay
reloadCounter `reloadCounter: 0`	pure "go again" signal for the fetch autorun, the same role `reloadCounter` plays in the three fetch families: after a fetch error every other input is unchanged, so without it nothing can rewake the fetch	ChordVariantDisplay
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

Getters

Member	Description	Defined by
view `ModelInstanceTypeProps<_OverrideProps<{ id: IOptionalIType<…>; displayName: IMaybe<…>; minimized: IOptionalIType<…>; }, { ...; }>> & ... 10 more ... & IStateTreeNode<...>`		ChordVariantDisplay
fetchInert `boolean`	Same name and same meaning as `FetchMixin.fetchInert` and `SyntenyFetchStateMixin.fetchInert`, on a display that composes neither: the fetch autorun deliberately never runs while the view holds no displayed regions, and the view menu offers its track selector from the import form — so a track opened there rests forever in "fetch not started". Two readers, which is why it is one name: the SVG export (`awaitSvgReady` is an unbounded `when`, so it would hang with the dialog's spinner up and nothing said) and the dev-only retry check the fetch skeleton installs, which would otherwise call that decline a dead Retry button.	ChordVariantDisplay
ready `boolean`	both halves of a chord render: the features, and the refName map that translates the assembly's names to the adapter's. `blocksForRefs` falls back to untranslated names while the map is in flight, so a render that only waited on features could draw a figure with every chord silently dropped (whenever the adapter names differ, e.g. `1` vs `chr1`).	ChordVariantDisplay
svgReady `boolean`	Off-screen SVG export gate: "Export SVG" waits on this before drawing (see the SVG export guide). Chord displays are non-rectangular (radial), so on screen they keep a bespoke `<DisplayError>` error UI instead of `SvgChrome`; the export has no box to draw one in either, and doesn't try — `awaitSvgReady` fails the export on a chord track that wouldn't load. Same shared `computeSvgReady` policy as every other display, awaited the same shared way — no inlined `when()`. No `regionTooLarge` state, and a chord fetch covers the whole view at once, so `ready` (features and refName map arrived) is the whole freshness axis.	ChordVariantDisplay
radiusPx `number`		ChordVariantDisplay
bezierRadius `number`	the deepest a chord bows toward the center, which a chord straight across the circle reaches. A shorter one bows in proportion to how far apart its ends are — see `chordControlRadius`	ChordVariantDisplay
blocksForRefs `Record<string, Slice>`	every slice of the circle, keyed by the refName a feature off this display's adapter carries. An elided slice answers to each of the refNames it swallowed	ChordVariantDisplay
selectedFeatureId `string \| undefined`		ChordVariantDisplay
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

Methods

Member	Description	Defined by
renderSvg `(_opts: ExportSvgOptions & { theme?: ThemeOptions \| undefined; }) => Promise<Element \| null>`		ChordVariantDisplay
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
trackMenuItems `() => MenuItem[]`		BaseDisplay

Actions

Member	Description	Defined by
onChordClick `(feature: Feature) => void`		ChordVariantDisplay
openErrorDialog `() => void`		ChordVariantDisplay
setFeatures `(features: Feature[] \| undefined) => void`		ChordVariantDisplay
setRefNameMap `(refNameMap: Record<string, string> \| undefined) => void`		ChordVariantDisplay
reload `() => void`		ChordVariantDisplay
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

ChordVariantDisplay

Example usage#

Properties#

Volatiles#

Getters#

Methods#