# BaseChordDisplay Auto-generated @jbrowse/mobx-state-tree API for the current JBrowse release — see [pluggable elements](https://jbrowse.org/jb2/docs/developer_guide/) for concepts. Provided by the `circular-view` plugin. [View source](https://github.com/GMOD/jbrowse-components/blob/main/plugins/circular-view/src/chords/BaseChordDisplay.ts). What the circular view's chord and ribbon displays share: the features and the per-assembly name tables that place them, 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 | Member | Description | Defined by | | --- | --- | --- | | **bezierRadiusRatio**
bezierRadiusRatio: types.stripDefault(types.number, 0.1) | how deep a chord bows toward the center, as a fraction of the radius; one straight across the circle reaches it, a shorter one bows in proportion to its span | BaseChordDisplay | | **id**
id: ElementId | | [BaseDisplay](../basedisplay#property-id) | | **type**
type: types.string | | [BaseDisplay](../basedisplay#property-type) | ## Volatiles | Member | Description | Defined by | | --- | --- | --- | | **features**
features: undefined as Feature[] | undefined | | BaseChordDisplay | | **adapterNames**

adapterNames: undefined as Record<string, AdapterNames> | undefined

| one entry per assembly of the track on the circle, keyed by canonical name | BaseChordDisplay | | **reloadCounter**
reloadCounter: 0 | the fetch's pure "go again" signal | BaseChordDisplay | | **error**
error: undefined as unknown | | [BaseDisplay](../basedisplay#volatile-error) | | **statusMessage**
statusMessage: undefined as string | undefined | | [BaseDisplay](../basedisplay#volatile-statusmessage) | | **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](../basedisplay#volatile-statusprogress) | ## Getters | Member | Description | Defined by | | --- | --- | --- | | **view**

ModelInstanceTypeProps<_OverrideProps<Omit<Omit<…>, never>, { ...; }>> & ... 15 more ... & IStateTreeNode<...>

FC<{ model: ModelInstanceTypeProps<{ id: IOptionalIType<ISimpleType<string>, [undefined]>; type: ISimpleType<string>; }> & { ...; } & { ...; } & IStateTreeNode<...>; }> | null

| | [BaseDisplay](../basedisplay#getter-displayblurb) | | **adapterConfig**
Record<string, unknown> | | [BaseDisplay](../basedisplay#getter-adapterconfig) | | **isMinimized**
boolean | Returns true if the parent track is minimized. Used to skip expensive operations like autoruns when track is not visible. | [BaseDisplay](../basedisplay#getter-isminimized) | | **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](../basedisplay#getter-hoveredfeature) | | **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](../basedisplay#getter-featurenoun) | | **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](../basedisplay#getter-featurewidgettype) | ## Methods | Member | Description | Defined by | | --- | --- | --- | | **sliceFor**
(assemblyName: string | undefined, refName: string) => Slice | the slice one end of a feature lands on. A feature that names no assembly, as a VCF record does not, is on the track's first assembly. | BaseChordDisplay | | **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](../basedisplay#method-renderingprops) | | **trackMenuItems**
() => MenuItem[] | | [BaseDisplay](../basedisplay#method-trackmenuitems) | ## Actions | Member | Description | Defined by | | --- | --- | --- | | **openErrorDialog**
() => void | | BaseChordDisplay | | **setFeatures**
(features: Feature[] | undefined) => void | | BaseChordDisplay | | **setAdapterNames**
(names: Record<string, AdapterNames> | undefined) => void | | BaseChordDisplay | | **reload**
() => void | | BaseChordDisplay | | **setStatusMessage**
(status?: RpcStatus | undefined) => void | | [BaseDisplay](../basedisplay#action-setstatusmessage) | | **setError**
(error?: unknown) => void | | [BaseDisplay](../basedisplay#action-seterror) | | **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](../basedisplay#action-clearhoveredfeature) | | **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. 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`. 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](../basedisplay#action-applydisplaysettings) |