Skip to main content

BaseDisplay

Auto-generated @jbrowse/mobx-state-tree API for the current JBrowse release — see pluggable elements for concepts. Built into JBrowse core. View source.

Properties

MemberDescription
id
id: ElementId
type
type: types.string

Volatiles

MemberDescription
error
error: undefined as unknown
statusMessage
statusMessage: undefined as string | undefined
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.

Getters

MemberDescription
parentTrack
AbstractTrackModel
RenderingComponent
FC<…>
DisplayBlurb
FC<{ model: ModelInstanceTypeProps<{ id: IOptionalIType<ISimpleType<string>, [undefined]>; type: ISimpleType<string>; }> & { ...; } & { ...; } & IStateTreeNode<...>; }> | null
adapterConfig
Record<string, unknown>
isMinimized
boolean		Returns true if the parent track is minimized. Used to skip expensive operations like autoruns when track is not visible.
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.
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.
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.

Methods

MemberDescription
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
trackMenuItems
() => MenuItem[]

Actions

MemberDescription
setStatusMessage
(status?: RpcStatus | undefined) => void
setError
(error?: unknown) => void
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.
reload
() => void		base display reload does nothing, see specialized displays for details
applyDisplaySettings
(settings: Record<…>, options?: { allowSetters?: boolean | undefined; } | undefined) => { applied: string[]; unapplied: string[]; failed: { key: string; error: string; }[]; }
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.