Skip to main content

BaseChordDisplay

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.

What the circular view's chord and ribbon displays share: the features, the slice index a feature end is looked up in, and the lifecycle getters ChordDisplayFrame publishes. A track draws on the arcs of its own assemblies, so a one-genome variant track on a two-genome circle fetches and places only that genome's chords.

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

Properties

MemberDescriptionDefined by
id
id: ElementId		BaseDisplay
type
type: types.string		BaseDisplay

Volatiles

MemberDescriptionDefined by
features
features: undefined as Feature[] | undefined		BaseChordDisplay
reloadCounter
reloadCounter: 0		the fetch's pure "go again" signalBaseChordDisplay
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

MemberDescriptionDefined by
view
ModelInstanceTypeProps<_OverrideProps<_OverrideProps<_OverrideProps<Omit<Omit<…>, never>, _OverrideProps<...>>, { ...; }>, { ...; }>> & ... 30 more ... & IStateTreeNode<...>
BaseChordDisplay
trackAssemblyNames
string[]		the track's assemblies that are on the circle, canonical and in the order the circle lays them outBaseChordDisplay
fetchInert
boolean		nothing of this track's is on the circle, so the fetch never runs; the SVG export's wait and the retry contract check both read itBaseChordDisplay
loaded
boolean		BaseChordDisplay
ready
boolean		BaseChordDisplay
displayError
unknown		what the error ring showsBaseChordDisplay
svgReady
boolean		the off-screen export gate, on the shared computeSvgReady policy. A radial display has no box to draw an error in, so the export fails rather than exporting a messageBaseChordDisplay
displayPhase
DisplayStatusPhase		BaseChordDisplay
radiusPx
number		BaseChordDisplay
bezierRadiusRatio
number		how far from the center a chord across the circle passes, as a fraction of the radius; a shorter chord bows less, in proportion to its spanBaseChordDisplay
bezierRadius
number		BaseChordDisplay
sliceIndex
Record<string, Slice>		every slice of the circle, keyed by canonical assembly AND refName: two genomes on one circle can each carry a chr1. An elided slice answers to each refName it swallowed.BaseChordDisplay
drawnFeatures
Feature[] | undefined		what the chord components drawBaseChordDisplay
selectedFeatureId
string | undefined		BaseChordDisplay
hoveredFeatureId
string | undefined		the feature under the pointer, which the view hit-tests for every chord display at onceBaseChordDisplay
chordStage
ChordStage		the polar stage as the canvas and the pointer see it, rotation inBaseChordDisplay
figureStage
ChordStage		the polar stage on the unrotated figure, which the view's SVG turns: what the export and the highlight paths are placed onBaseChordDisplay
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 FetchMixin.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; }		The widget openFeatureWidget opens for one of this display's features. Displays may override it. The default is the generic feature widget, for displays drawing plain features.

Displays whose features are a specific kind (a read, a variant, a synteny block) override it, including the id: two displays naming one id share the drawer panel, which suits two displays showing the same kind of feature.		BaseDisplay
plotKeys
string[]		The grammar settings this display's config declares, by slot name (PLOT_VOCABULARY): what "Edit plot..." edits. Empty on a display with none, which then offers no editor.BaseDisplay
plot
Plot		Those settings as declared, defaults left off and a shorthand written as a config file writes it. An agent edits a structuredClone of it, checks it with plotProblems and hands it to applyPlot.BaseDisplay
plotExamples
readonly PlotExample[]		The worked examples this display type declares, which "Edit plot..." offers as buttons.BaseDisplay
configDocsUrl
string		This display type's page in the config reference, which lists every setting it takes.BaseDisplay

Methods

MemberDescriptionDefined by
assemblyOf
(assemblyName: string | undefined) => string | undefined		the assembly on the circle a feature names, in whatever spelling the adapter wrote. A feature that names none, as a VCF record does not, is on the track's first assembly.BaseChordDisplay
canonicalRefName
(assemblyName: string, refName: string) => string		a refName as the adapter wrote it, in the assembly's canonical spellingBaseChordDisplay
sliceFor
(assemblyName: string | undefined, refName: string) => Slice | undefined
the slice one end of a feature lands onBaseChordDisplay
axisSlice
(assemblyName: string | undefined, refName: string) => AxisSlice | undefined
the slice of the unrolled axis one end of a feature lands onBaseChordDisplay
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 callbacksBaseDisplay
trackMenuItems
() => MenuItem[]		BaseDisplay
liftPlot
(draft: Plot) => AnyConfigurationModel		A draft as the config would hold it, merged over plot, throwing what a config file would be refused for. Nothing on the display changes.BaseDisplay
plotProblems
(draft: Plot) => string[]		What a draft would report once applied, throwing a refusal as liftPlot does: what its colour objects and scales.y say together that cannot be drawn as written. A display with a rule list over its settings overrides it; the draft still applies, and draws what it can.BaseDisplay
plotWrites
(draft: Plot) => Record<string, unknown>		What applying a draft would write, by setting: the lifted value where it differs from plot, null where it resets one. Throws a refusal.BaseDisplay

Actions

MemberDescriptionDefined by
openErrorDialog
() => void		BaseChordDisplay
setFeatures
(features: Feature[] | undefined) => void		BaseChordDisplay
reload
() => void		BaseChordDisplay
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 (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
applyDisplaySettings
(settings: Record<string, unknown>, options?: { allowSetters?: boolean | undefined; } | undefined) => { applied: string[]; unapplied: UnappliedSetting[]; failed: { ...; }[]; }
Apply a set of display settings to the live display, and report which were applied. Each key runs through the display config schema's preProcessSnapshot (shorthand expansions and legacy-key migrations, as showTrackGeneric applies to a session spec's inline track keys), then writes the matching config slot. A key naming a sub-schema (facet, color) replaces the whole object, its string shorthand lifted by that schema, and null clears it. Keys that are not slots come back in unapplied as { key, reason }, so a caller can tell a misspelling from a key that has an action instead of a slot.

allowSetters also routes a non-slot key to a single-argument action named set<Key>. It is off by default because session specs, share links and embeds pass untyped JSON here, and a default fallback would let them call internal setters (setError, setScrollTop, ...) and call multi-argument setters with one argument. A caller that wants a specific action can call it directly.

A key whose write threw is reported in failed. Only failed means the caller passed a bad value. unapplied needs the caller's own context to read: showTrackGeneric spreads the same settings into the display's snapshot, so a declared prop (resolution) has already landed by the time it reports here, while the restyle path spreads nothing and every entry there did nothing.

A per-key error does not abort the remaining keys. A caller mid-showTrack has already pushed the track, and one rejected value should not leave it half-configured.		BaseDisplay
applyPlot
(draft: Plot) => void		Write a draft over plot: each setting it changes is replaced whole, so a member left out of an object goes back to its default, and null resets the setting. A draft the schema refuses, or naming a setting outside the plot, throws before anything is written.BaseDisplay