ChordSyntenyDisplay
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 SyntenyTrack: each alignment is drawn as a
ribbon between its span on one side and its mate's span on the other, so an
inversion reads as a twist. The track config below is what creates it; its
colors are the config slots on ChordSyntenyDisplay:
{
type: 'SyntenyTrack',
trackId: 'volvox_self',
name: 'Volvox self-alignment',
assemblyNames: ['volvox', 'volvox'],
adapter: {
type: 'PAFAdapter',
uri: 'https://example.com/volvox_self.paf',
queryAssembly: 'volvox',
targetAssembly: 'volvox',
},
displays: [
{
type: 'ChordSyntenyDisplay',
displayId: 'volvox_self-ChordSyntenyDisplay',
},
],
}
A track aligning two assemblies needs both of them on the circle, which is
the view's assembly: ['hg38', 'mm39'] — see the
synteny track guide.
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 |
|---|---|---|
typetype: types.literal('ChordSyntenyDisplay') | ChordSyntenyDisplay | |
bezierRadiusRatiobezierRadiusRatio: types.stripDefault(types.number, 0.1) | ChordSyntenyDisplay | |
configurationconfiguration: ConfigurationReference(configSchema) | ChordSyntenyDisplay | |
idid: ElementId | BaseDisplay |
Volatiles
| Member | Description | Defined by |
|---|---|---|
featuresfeatures: undefined as Feature[] | undefined | ChordSyntenyDisplay | |
| adapterNames | one entry per assembly the circle draws, keyed by the canonical name | ChordSyntenyDisplay |
reloadCounterreloadCounter: 0 | pure "go again" signal for the fetch autorun, the same role reloadCounter plays in the three fetch families | ChordSyntenyDisplay |
errorerror: undefined as unknown | BaseDisplay | |
statusMessagestatusMessage: undefined as string | undefined | BaseDisplay | |
statusProgressstatusProgress: 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 | ChordSyntenyDisplay | |
fetchInertboolean | Same name and same meaning as FetchMixin.fetchInert, on a display that does not compose it: the fetch autorun never runs while the view holds no displayed regions, so a track opened from the import form's track selector rests forever in "fetch not started". The SVG export's unbounded when and the retry-contract check both read it. | ChordSyntenyDisplay |
readyboolean | both halves of a ribbon render: the alignments, and the per-assembly name tables that place each of their two ends | ChordSyntenyDisplay |
svgReadyboolean | Off-screen SVG export gate, on the same shared computeSvgReady policy as every other display. A radial display has no box to draw an error in, so awaitSvgReady fails the export rather than exporting a message. | ChordSyntenyDisplay |
displayPhaseDisplayStatusPhase | ChordSyntenyDisplay | |
radiusPxnumber | ChordSyntenyDisplay | |
bezierRadiusnumber | the deepest a ribbon bows toward the center, which one straight across the circle reaches — see chordControlRadius | ChordSyntenyDisplay |
sliceIndexRecord<string, Slice> | every slice of the circle, keyed by the assembly AND refName a feature off this display's adapter carries. Both halves are needed: a two- assembly circle can carry a chr1 twice, and a refName-keyed table answers whichever slice was written last. An elided slice answers to each of the refNames it swallowed. | ChordSyntenyDisplay |
selectedFeatureIdstring | undefined | ChordSyntenyDisplay | |
featureNounstring | ChordSyntenyDisplay | |
featureWidgetType{ type: string; id: string; } | the panel the linear synteny displays open for the same record, so a ribbon clicked on the circle and a ribbon clicked in a synteny view share one drawer entry | ChordSyntenyDisplay |
parentTrackAbstractTrackModel | BaseDisplay | |
RenderingComponentFC<…> | BaseDisplay | |
| DisplayBlurb | BaseDisplay | |
adapterConfigRecord<string, unknown> | BaseDisplay | |
isMinimizedboolean | Returns true if the parent track is minimized. Used to skip expensive operations like autoruns when track is not visible. | BaseDisplay |
hoveredFeatureunknown | 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 |
Methods
| Member | Description | Defined by |
|---|---|---|
| sliceFor | the slice one end of an alignment lands on. The assembly falls back to the circle's only one, for an adapter that leaves it off a mate. | ChordSyntenyDisplay |
| renderSvg | ChordSyntenyDisplay | |
| renderingProps | 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 |
() => MenuItem[] | BaseDisplay |
Actions
| Member | Description | Defined by |
|---|---|---|
onRibbonClick(feature: Feature) => void | ChordSyntenyDisplay | |
openErrorDialog() => void | ChordSyntenyDisplay | |
setFeatures(features: Feature[] | undefined) => void | ChordSyntenyDisplay | |
setAdapterNames(names: Record<string, AdapterNames> | undefined) => void | ChordSyntenyDisplay | |
reload() => void | ChordSyntenyDisplay | |
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 |
| applyDisplaySettings | Apply a bag of display settings to the LIVE display, and report what landed. Each key runs through the display config schema's preProcessSnapshot (shorthand expansions, legacy-key migrations — the same lowering a session spec's inline track keys get in showTrackGeneric), then writes the matching config slot. Keys that are not slots come back in unapplied rather than vanishing: the settings vocabulary's historical failure mode is the silently dropped key.allowSetters additionally routes a non-slot key to a conventionally named single-argument set<Key> action. Opt-in, never the default: the declarative surfaces (session specs, share links, embeds) feed this whole bags of untyped JSON, and a blanket fallback would let them reach internal setters (setError, setScrollTop, ...) and call multi-argument setters with one argument. A caller that wants a specific action can also simply call it.A key whose write THREW is reported separately, in failed — it is the only one of the three that means the caller got something wrong, and the only one worth a notification. unapplied is not: at the showTrackGeneric call site it also collects keys that surface consumed itself (type) and MST display props the display snapshot already applied (resolution), so treating it as "dropped" would report a correct call as broken.Per-key errors do not abort the rest of the bag — a caller mid- showTrack has already pushed the track, and one rejected value must not strand a half-configured track. | BaseDisplay |