LinearGenomeView
Auto-generated @jbrowse/mobx-state-tree API for the current JBrowse release —
see pluggable elements for concepts. Provided by the
linear-genome-view plugin.
View source.
Example usage
A LinearGenomeView is what you hand-author under defaultSession.views. The
init shorthand fills in displayedRegions/bpPerPx/offsetPx for you:
defaultSession: {
name: 'My session',
views: [
{
type: 'LinearGenomeView',
// plain persisted props sit alongside init, not inside it
colorByCDS: true,
init: {
assembly: 'hg38',
loc: 'chr1:1,000,000-1,100,000',
tracks: ['genes', 'alignments'],
},
},
],
}init holds only keys that need on-attach resolution — also tracklist, nav,
highlight (see the init property below). Plain view props like colorByCDS,
showAminoAcids, showCenterLine, trackLabels, showHighlightChips are set
directly on the view (MST restores them natively). At runtime the same model is
driven imperatively — every property and action below is reachable on
viewState.session.views[0]:
const view = viewState.session.views[0]
await view.navToLocString('chr1:2,000,000-2,100,000')
view.showTrack('alignments')
view.zoomTo(view.bpPerPx * 2) // zoom out 2xMembers a composed model contributes are listed here too, so these tables are the whole surface.
Properties
| Member | Description | Defined by |
|---|---|---|
idid: ElementId | LinearGenomeView | |
typetype: types.literal('LinearGenomeView') as unknown as string | this is a string instead of the const literal 'LinearGenomeView' to reduce some typescripting strictness, but you should pass the string 'LinearGenomeView' to the model explicitly | LinearGenomeView |
windowStartBpwindowStartBp: types.stripDefault(types.number, 0) | Left edge of the viewport, in linearized bp — the concatenated displayedRegions space that offsetPx indexes, which carries no inter-region padding, so the two differ only by bpPerPx. May be negative, which is the view scrolled past the left end.The viewport is stored as the genomic WINDOW it frames rather than as the pixels that framed it, because pixels mean nothing without the width they were measured at and a snapshot does not carry one. Storing them anyway is why a session authored in a 1000px window used to open at 500px showing half the region its author was looking at, while the same location as a &loc= opened correctly — the two ways to share a view disagreed, and only the one that stores intent was right. | LinearGenomeView |
windowWidthBpwindowWidthBp: types.stripDefault(types.number, 0) | Width of the viewport in bp. Zero means "not established yet": no width has been measured, so there is nothing to divide by. The first measure fills it in, and bpPerPx is windowWidthBp / width from then on. | LinearGenomeView |
legacyBpPerPxlegacyBpPerPx: types.stripDefault(types.number, 0) | MIGRATION ONLY, and safe to delete once pre-window sessions are no longer in circulation. A snapshot written before the window was stored carries offsetPx and bpPerPx but not the width they were measured at, so the window they framed cannot be recovered. windowStartBp can (it is offsetPx * bpPerPx, no width needed); the width in bp cannot. This carries the old bpPerPx to the first measure, which adopts it at whatever width arrives — exactly what the old code did — and clears this. So an old link keeps its old behavior rather than being reinterpreted, and everything authored since restores its window. | LinearGenomeView |
| displayedRegions | currently displayed regions, can be a single chromosome, arbitrary subsections, or the entire set of chromosomes in the genome, but it not advised to use the entire set of chromosomes if your assembly is very fragmented | LinearGenomeView |
| tracks | array of currently displayed tracks state models instances | LinearGenomeView |
hideHeaderhideHeader: types.stripDefault(types.boolean, false) | drop the header bar entirely — location box, navigation buttons and overview | LinearGenomeView |
hideHeaderOverviewhideHeaderOverview: types.stripDefault(types.boolean, false) | keep the header, drop the whole-chromosome overview strip below it | LinearGenomeView |
hideNoTracksActivehideNoTracksActive: types.stripDefault(types.boolean, false) | suppress the "No tracks active" placeholder, for an embed that opens with no tracks on purpose | LinearGenomeView |
| trackSelectorType | vestigial: the hierarchical selector is the only one that exists, so this value is ignored. Retained because saved sessions and configs persist it. | LinearGenomeView |
| showCenterLine | show the "center line" | LinearGenomeView |
| showCytobands | whether to show the "cytobands" in the overview scale bar (the resolved, capability-gated value is the effectiveShowCytobands getter) | LinearGenomeView |
| trackLabels | how to display the track labels, can be "overlapping", "offset", or "hidden", or empty string "" (which results in the LinearGenomeViewPlugin config default being used). the resolved value is the effectiveTrackLabels getter. see LinearGenomeViewPlugin https://jbrowse.org/jb2/docs/config/lineargenomeviewplugin/ docs for how conf is used | LinearGenomeView |
showGridlinesshowGridlines: types.stripDefault(types.boolean, true) | show the "gridlines" in the track area | LinearGenomeView |
labelsVisiblelabelsVisible: types.stripDefault(types.boolean, true) | controls whether highlight/bookmark chip labels are shown inline | LinearGenomeView |
| colorByCDS | color CDS segments by reading frame | LinearGenomeView |
| showAminoAcids | draw translated codons on coding features once zoomed in far enough: an alternating per-codon shading, and the amino acid letters on top of it at base-level zoom. Independent of colorByCDS, which only recolors the segments by frame. | LinearGenomeView |
| showTrackOutlines | show the track outlines | LinearGenomeView |
scalebarOnlyscalebarOnly: types.stripDefault(types.boolean, false) | when true, only the header and coordinate scalebar are rendered | LinearGenomeView |
initinit: types.frozen<InitState | undefined>() | transient declarative launch spec: assembly + optional location, tracks, and highlights to apply once the view attaches. It is applied by the afterAttach autorun and then cleared (setInit(undefined)), so a saved session never retains it. Shared by all three launch surfaces — URL params, createViewState(), and session/config JSON. example: json { "assembly": "hg19", "loc": "chr1:1,000,000-2,000,000", "tracks": ["genes", "variants"] } | LinearGenomeView |
displayNamedisplayName: types.maybe(types.string) | displayName is displayed in the header of the view, or assembly names being used if none is specified | BaseViewModel |
minimizedminimized: types.stripDefault(types.boolean, false) | collapse the view to its header bar, keeping it in the session rather than closing it | BaseViewModel |
| highlight | translucent highlight bands, seeded from URL params or session JSON and added interactively via the rubber-band menu | HighlightsMixin |
showHighlightChipsshowHighlightChips: types.stripDefault(types.boolean, false) | pins the interactive highlight chip (link icon + context menu) to every highlight band; off by default, where a band instead reveals its chip while the pointer is in it. This is what a screenshot needs, since nothing hovers in one | HighlightsMixin |
Volatiles
| Member | Description | Defined by |
|---|---|---|
volatileWidthvolatileWidth: undefined as number | undefined | LinearGenomeView | |
minimumBlockWidthminimumBlockWidth: 3 | LinearGenomeView | |
draggingTrackIddraggingTrackId: undefined as undefined | string | LinearGenomeView | |
lastTrackDragYlastTrackDragY: undefined as undefined | number | LinearGenomeView | |
volatileErrorvolatileError | LinearGenomeView | |
trackRefstrackRefs | LinearGenomeView | |
coarseDynamicBlockscoarseDynamicBlocks: [] as ContentBlock[] | LinearGenomeView | |
coarseTotalBpcoarseTotalBp: 0 | LinearGenomeView | |
coarseBpPerPxcoarseBpPerPx: self.legacyBpPerPx || 1 | LinearGenomeView | |
leftOffsetleftOffset: undefined as undefined | BpOffset | LinearGenomeView | |
rightOffsetrightOffset: undefined as undefined | BpOffset | LinearGenomeView | |
isScalebarRefNameMenuOpen: false | LinearGenomeView | |
scalebarRefNameClickPendingscalebarRefNameClickPending: false | LinearGenomeView | |
volatileGuidesvolatileGuides: [] as VolatileGuide[] | temporary vertical guides that can be set by displays (e.g., LD display hover) | LinearGenomeView |
widthwidth: 800 | BaseViewModel | |
bodyMountedbodyMounted: true | Whether the container has this view's body in the DOM.ViewContainer mounts a view's body only while an IntersectionObserver says it is on screen, to hold the app under the WebGL2 context ceiling (reference/GPU_CONTEXT_BUDGET.md). A view below the fold therefore has no canvas, so nothing ever calls markCanvasDrawn and the pre-first-paint term of displayPhase pins every display in it at loading with nothing left to resolve it — which parks [data-app-phase="ready"] for the whole app on a view the user cannot see.Defaults true so the containers that always mount a body — embedded views, workspace panels, and any test rendering a display directly — are unaffected and need not set it. The raw flag, written by this view's own container. A display asks effectiveBodyMounted instead, because a nested view has no container of its own. | BaseViewModel |
Getters
| Member | Description | Defined by |
|---|---|---|
bpPerPxnumber | corresponds roughly to the zoom level, base-pairs per pixel. Zero before a width is measured, which is the same not-yet-measured sentinel Base1DView uses and which displayedRegionsTotalPx and the offset getters already guard for. Reads volatileWidth rather than the width getter on purpose: that one throws when unmeasured, and these are read from the first render. | LinearGenomeView |
offsetPxnumber | corresponds roughly to the horizontal scroll of the LGV | LinearGenomeView |
scrollZoomboolean | scroll-to-zoom is a global, personal preference resolved from the session; toggling it in any view applies everywhere | LinearGenomeView |
pinnedTracksany[] | LinearGenomeView | |
unpinnedTracksany[] | LinearGenomeView | |
effectiveTrackLabelsany | the effective track labels setting, resolving the stored trackLabels against the LinearGenomeViewPlugin config default | LinearGenomeView |
widthnumber | LinearGenomeView | |
trackWidthPxnumber | width minus track outline borders (1px each side when shown) | LinearGenomeView |
assemblyNamesstring[] | LinearGenomeView | |
assemblyDisplayNamesstring[] | LinearGenomeView | |
isTopLevelViewboolean | checking if lgv is a 'top-level' view is used for toggling pin track capability, sticky positioning | LinearGenomeView |
stickyViewHeadersboolean | only uses sticky view headers when it is a 'top-level' view and session allows it | LinearGenomeView |
scalebarDisplayPrefixstring | undefined | Assembly-name prefix for the scalebar refName labels, or undefined for none. A container view (e.g. LinearSyntenyView) opts its sub-views in by exposing showAssemblyNameInSubviewScalebar; duck-typed rather than matching a concrete view type so no upward plugin dependency is needed and any container can opt in. A wrong nesting depth simply yields no prefix — hence the hasParent guard, since getParent throws (rather than returning undefined) when the view sits shallower than depth 2. | LinearGenomeView |
assembliesNotFoundstring | undefined | LinearGenomeView | |
assemblyErrorsstring | LinearGenomeView | |
assembliesInitializedboolean | LinearGenomeView | |
| initAssembly | the assembly named by a pending init, or undefined when no init is set. init's assembly isn't in assemblyNames yet (that derives from displayedRegions, still empty pre-navigation), so init-phase readiness and error checks resolve it directly through here. | LinearGenomeView |
initializedboolean | LinearGenomeView | |
hasDisplayedRegionsboolean | LinearGenomeView | |
| loadingAssembly | The assembly whose load the spinner is waiting on: the one init names before navigation (it isn't in assemblyNames yet), else the first of the displayed assemblies that hasn't finished loading. | LinearGenomeView |
loadingMessagestring | undefined | What the spinner says. The assembly reports which of its files it is downloading, so this is "Downloading chromosome aliases" rather than a bare "Loading" for the part of startup that actually takes time. Falls back once the assembly is loaded and the remaining wait is the init autorun's own navigation, which is local. | LinearGenomeView |
loadingProgressnumber | undefined | Determinate fraction for the spinner's bar, when the assembly load reports one (a whole-file download with a Content-Length) | LinearGenomeView |
loadingSourcestring | undefined | The URL the assembly load is currently fetching, when the phase named one. Only the stalled-load notice reads it — see ViewLoadingScreen. | LinearGenomeView |
hasSomethingToShowboolean | LinearGenomeView | |
boolean | init is set but its async navigation (the afterAttach autorun) hasn't populated displayedRegions yet. initialized can already be true here (it only tracks assembly readiness), so without this the container would mount over empty regions and pxToBp/hover would throw.Not dotplot's or synteny's initPending, which is the bare !!self.init — "an init blob has not been applied" — and which those views read from their settled gate rather than from showLoading. This one is narrower on purpose: it closes only the window where there is nothing on screen. Once navigation has produced regions the view is usable and gets shown, even though init is still set while the tracks and highlights land. Renamed away from the shared spelling because the two predicates disagree exactly there, and the bare name reads as theirs. | LinearGenomeView |
showLoadingboolean | Whether to show a loading indicator instead of the import form or view | LinearGenomeView |
showImportFormboolean | Whether to show the import form | LinearGenomeView |
readyboolean | Is there anything to draw yet? The gate anything reading block geometry — a ruler, a scalebar, a display — has to pass first, because width/staticBlocks throw by design before the view has been measured and navigated.Not initialized, which is the trap this getter exists to close. That one answers "have the assembly's regions loaded", which is only the first of two async steps: navigating then populates displayedRegions, and in the window between the two initialized is already true while there is still nothing on screen. showLoading folds in awaitingInitNavigation, the getter that exists for exactly that gap.error is the third outcome and is why this is not a bare !showLoading: a failed assembly load also ends the loading state, so that alone would mount over the wreckage. Read error yourself if you want to draw it. | LinearGenomeView |
statusViewStatus | The same question as ready with the other three outcomes named, for a host that draws its own chrome and has to render all four. See computeViewStatus, whose precedence this defers to — and note its ready is narrower than the getter above, which is true when nothing has told the view where to look. | LinearGenomeView |
scalebarHeightnumber | LinearGenomeView | |
trackLeadingChromenumber | What TrackContainer puts above a track's rendering container: the gap over its Paper, and the Paper's own top border when outlines are on. | LinearGenomeView |
trackTrailingChromenumber | ...and what it puts below: the resize divider, plus the matching bottom border. | LinearGenomeView |
trackChromeHeightnumber | A track's full cost beyond its display height. The track label is not counted, and cannot be: an offset label is an in-flow box whose height is whatever the theme renders a Paper of icon buttons at — 31.140625px on the stock theme, and not a number this file can derive. So these getters are exact while labels are hidden or overlapping, and short by one label box per labelled track otherwise. Anything needing the offset to the pixel with labels showing measures the DOM; BreakpointSplitViewOverlay does, and falls back to this arithmetic only for a track with no mounted div. | LinearGenomeView |
headerHeightnumber | LinearGenomeView | |
rubberbandTopnumber | Where the scalebar pins when the view's chrome is sticky: everything stacked above it, which is the view's own title bar plus this view's header. Expressed from headerHeight rather than re-summing its constants — the two are the same box, and a second spelling of the sum is free to drift from the first while both typecheck. | LinearGenomeView |
pinnedTracksTopnumber | LinearGenomeView | |
trackHeightsnumber | LinearGenomeView | |
trackHeightsWithChromenumber | LinearGenomeView | |
heightnumber | LinearGenomeView | |
totalBpnumber | LinearGenomeView | |
fitBpPerPxnumber | LinearGenomeView | |
maxBpPerPxnumber | The zoom-out limit. This view's own fit, except while a container holds it on a shared scale coarser than that — a small genome next to a large one, drawn short so the two compare by length. Raising the LIMIT is what makes such a scale survive: written past the limit instead, it is undone by the first thing that clamps — a wheel tick, a rubberband, a setDisplayedRegions — which is how the dotplot's locked aspect ratio once turned "zoom out" into a zoom in (axisMaxBpPerPx). Here every route to a zoom clamps against the same ceiling, so full zoom-out LANDS on the shared scale. | LinearGenomeView |
number | The zoom-out ceiling a containing comparative view holds this row to, or 0 for a standalone view, a mode that is off, and a stack that cannot answer yet. Pulled rather than pushed down into a volatile: the number is a function of every row's fit, all of which move on a resize, and a stored copy would be stale by the next layout. | LinearGenomeView |
minBpPerPxnumber | LinearGenomeView | |
errorunknown | LinearGenomeView | |
maxOffsetnumber | LinearGenomeView | |
minOffsetnumber | LinearGenomeView | |
displayedRegionsOrientationRegionsOrientation | Whether the displayed regions read left-to-right, right-to-left, or some of each. horizontallyFlip reverses the order and flips every region at once, so a flipped row is uniformly reversed and mixed takes going out of your way — the scalebar label menu's per-region "Reverse region". Read off displayedRegions rather than off blocks because blocks cover the window and this is a fact about the row. | LinearGenomeView |
displayedRegionsTotalPxnumber | LinearGenomeView | |
trackMapMap<string, any> | LinearGenomeView | |
showsWholeChromosomeboolean | LinearGenomeView | |
canShowCytobandsboolean | an ideogram only reads correctly against an entire chromosome: on a sub-region it is a meaningless slice of bands, and the centromere shows up as a lone half-triangle | LinearGenomeView |
effectiveShowCytobandsboolean | the showCytobands setting gated by whether cytobands can be shown at all (whole chromosome + data present) — i.e. actually on screen | LinearGenomeView |
anyCytobandsExistboolean | LinearGenomeView | |
cytobandOffsetnumber | the cytoband is displayed to the right of the chromosome name, and that offset is calculated manually with this method | LinearGenomeView |
isTrackSelectorOpenboolean | LinearGenomeView | |
overviewLayoutViewLayout | geometry of the overview scalebar — derived from displayedRegions, width, and cytobandOffset so it stays cached by MobX | LinearGenomeView |
staticBlocksBlockSet | static blocks are an important concept jbrowse uses to avoid re-rendering when you scroll to the side. when you horizontally scroll to the right, old blocks to the left may be removed, and new blocks may be instantiated on the right. tracks may use the static blocks to render their data for the region represented by the block | LinearGenomeView |
dynamicBlocksBlockSet | dynamic blocks represent the exact coordinates of the currently visible genome regions on the screen. they are similar to static blocks, but static blocks can go offscreen while dynamic blocks represent exactly what is on screen | LinearGenomeView |
overviewBlocksBaseBlock[] | all overview scalebar blocks (content + elided), laid out on the overviewLayout. memoized so the scalebar doesn't recompute it per render | LinearGenomeView |
overviewRegionPxSpanPxSpan | undefined | leading/trailing pixel span of the visible regions projected onto the overviewLayout — the geometry of the overview's "you are here" rectangle, and of the top edge of the polygon drawn under it. Elided regions count: at whole-genome zoom the tail of an assembly is all coalesced tiny contigs, and stopping at the last content block left the rectangle short of (or, scrolled onto that tail, absent from) the polygon it sits on. | LinearGenomeView |
staticBlocksTranslateXnumber | The x shift that maps the staticBlocks frame onto the viewport: translateX(view.staticBlocksTranslateX) on one container places every gridlineTicks, scalebarLabels and paddingSpans entry at once, and a pan then moves that single transform rather than each child.The frame exists because those three are laid out across every displayed region rather than across the viewport — it overhangs on both sides — so their x values are stable under a scroll and only this number moves. scalebarRefNameLabels is the exception and says so: its transform is already a screen x, because a sticky label's position is a function of the scroll rather than of block geometry.The subtraction must happen here, in float64, and that is the load-bearing part. offsetPx is a whole-genome pixel coordinate — hg38 chr1 at base resolution is already past 1e10 — and a length that size does not survive the trip through CSS: the transform matrix is float32 by the time it reaches the compositor, where consecutive representable values at 1e10 are ~1024px apart, and layout saturates sooner still (Blink's LayoutUnit is int32 at 1/64px, so ±33.5M px). So the shape that looks obvious — lay an overlay out in absolute genome pixels, write translateX(-view.offsetPx) — does not lose a subpixel, it puts the row somewhere else entirely, and only on large assemblies at high zoom, which is not where anyone tests. Both operands here are large and their difference is bounded by the overhang (a block or two), so what reaches CSS is small and exact. Same rule as the GPU side, one layer up — agent-docs/reference/BP_PRECISION.md.Published because it is the one piece of coordinate arithmetic a host drawing its own chrome would otherwise have to know, and because having it written out at each call site is how the two in-tree copies came to disagree about rounding. Round it where the content is text (a fractional offset blurs a label); leave it alone for paths and boxes. | LinearGenomeView |
gridlineTicks{ x: number; major: boolean; }[] | Gridline tick positions (x relative to the staticBlocks frame), derived from staticBlocks + bpPerPx. Computed once and shared by every Gridlines instance (scalebar, main view, each pinned track) rather than recomputing the makeTicks loop per component. | LinearGenomeView |
scalebarLabels{ x: number; label: string; key: string; }[] | Scalebar coordinate labels (x in the staticBlocks frame + display text). Sibling of gridlineTicks sharing the same makeBlockTicks formula, so labels line up exactly with their gridlines. staticBlocks chop a region into ~800px chunks; groupContiguousBlocks merges them back per region so a label on an internal chunk boundary isn't clipped away by both neighbors — only genuine region edges clip a label. A run that can hold too few labels to make a ruler goes unnumbered ( tickLabelsWorthDrawing), the same rule the overview scalebar and the dotplot axes apply: with a whole genome displayed each chromosome catches one lone coordinate, which conveys no scale by itself and reads as the same number repeated across the row. | LinearGenomeView |
| scalebarRefNameLabels | The bold refName labels drawn along the scalebar, as plain data: {key, refName, displayedRegionIndex, lastDisplayedRegionIndex, sticky, transform, maxWidth, paddingLeft, text} each. One per run of same-refName regions, plus a "sticky" one pinned to the viewport's left edge naming the refName under it, so panning into a chromosome does not scroll its own name off the screen.Three rules live in here that a host drawing region names will otherwise rediscover the hard way, and two of them are invisible until the data is awkward: - the sticky label rides the rightmost run that has scrolled off the left, not the region's first block — that one is gone from staticBlocks entirely once you zoom into a region's interior, taking the chromosome name off screen at exactly the zoom where nothing else names it. - adjacent regions of the same refName (collapsed introns) get one label between them, not one each. That label names the whole run and is fitted to the whole run, and displayedRegionIndex / lastDisplayedRegionIndex bracket what it stands for. - a name is drawn whole or not at all, measured against the space its run leaves. Clipped to its own width, chr16 reads as chr1 — a different chromosome rather than a shortened name, which is why this is a fit test rather than an ellipsis.Viewport frame, unlike its siblings. transform is a screen x, already net of offsetPx, where gridlineTicks / scalebarLabels / paddingSpans are all in the staticBlocks frame. The sticky label's position is a function of offsetPx rather than of block geometry, so it has no fixed position in that frame — and for the same reason this getter recomputes on every scroll frame where those three do not.caption accompanies the labels: the chip at the row's left edge, saying which assembly the row is (a container view — synteny — opts into that through scalebarDisplayPrefix) and whether it is flipped. A [rev] there is a fact about the ROW; the same marker on a chromosome name means that one region, which only happens under mixed orientation. captionSpanPx is the width it takes, which the coordinate numbers stay out from under. The SVG export deliberately calls getScalebarRefNameLabels itself with no prefix rather than reading this, since it draws its own assembly name above the ruler. | LinearGenomeView |
| paddingSpans | Every span along the row that is not track data, as plain geometry in the staticBlocks frame — the same frame as gridlineTicks and scalebarLabels, so one translateX(staticBlocksTranslateX) places all three. Three kinds, and a host drawing its own chrome needs all of them:- seam: the 3px bar at a region's right edge. Displayed regions are laid out contiguously — calculateStaticBlocks emits boundary padding only before the first region and after the last — so this bar is the only thing separating two of them. Without it a two-region view reads as a one-region view scrolled somewhere strange. isRightEndOfDisplayedRegion is what marks it, and the right edge of the blocks currently loaded — which is what block geometry hands you — is not the same filter. - elided: a region too narrow to draw at this zoom. Whole-genome on a real assembly is mostly these — hg38 has 455 sequences and all but the 24 chromosomes land sub-pixel — so a host that skips them renders that tail as nothing at all. - boundary: past the start of the first region or the end of the last. Greying it is what makes the last region's seam read as the edge of a filled area rather than a rule floating in the track.Elided blocks get no seam even though they carry the flag: at the zoom where regions elide, one bar per region is a solid grey wall. PaddingBlocks is the in-tree consumer. The SVG export is deliberately NOT one: SVGRegionSeparators walks dynamicBlocks itself and draws only the seam, because elided and boundary are chrome for an interactive row rather than information a figure carries — striped grey saying "regions here are too narrow to draw" is noise in a static image, and at whole-genome zoom it would be most of the row. The seam is the one that must survive: regions lay out contiguously, so it is all that separates two of them. | LinearGenomeView |
totalWidthPxnumber | Integer-rounded sum of all visible block widths. Slightly less than view.width when the genome ends before the right edge; use view.width for SVG clip rects (display boundary) and this for paint canvas sizing (actual content width). | LinearGenomeView |
totalWidthPxWithoutBordersnumber | Like totalWidthPx but excluding inter-region boundary blocks. Used when column layout divides the canvas width by feature count. | LinearGenomeView |
visibleBpnumber | LinearGenomeView | |
hasVisibleContentboolean | Whether any part of a displayed region actually falls inside the viewport. False both when the view holds no regions at all and when it holds some but is scrolled entirely off them; either way there is no visible span for the scalebar, ruler and refName labels to describe, which is what the SVG export's header checks before drawing one. Distinct from hasDisplayedRegions, which only asks whether the view has been given regions, not whether any are on screen. | LinearGenomeView |
| visibleWholeBaseRegions | What is on screen, as regions that address whole bases — what a reader means by "the visible region" when they ask to fetch it, bookmark it or read it back in a locString field. visibleRegions below is the other half: pixels, and fractional by design. | LinearGenomeView |
| visibleRegions | Returns the currently visible content blocks with screen pixel positions and displayedRegionIndex guaranteed. Used by WebGL displays for per-region data fetching and rendering. | LinearGenomeView |
| bufferedVisibleRegions | visibleRegions expanded by a half-screen buffer on each side, clamped to displayedRegion bounds, with integer-rounded coordinates. Use this when fetching data that should extend slightly beyond the viewport for smooth scrolling. | LinearGenomeView |
visibleLocStringsstring | a single "combo-locstring" representing all the regions visible on the screen | LinearGenomeView |
settledDynamicBlocksContentBlock[] | What a debounced consumer clips to: the coarse blocks once the view has settled at least once, the live ones before that. The coarse blocks exist so a per-bp scan does not recompute on every animation frame during a pan or zoom — wiggle's autoscale domain, the alignments coverage scale and MAF's coverage band are the three — and while they are stale the answer is merely a frame or two old, which is what the debounce means. Empty is different in kind. A scan over no blocks yields no entries, and no entries is not a stale domain, it is the fallback one: [0,1], which draws a line plot blank and a density plot saturated. That window is the 500ms between a view initializing and the coarse autorun's first run, and data can now land inside it — the per-region fetch used to be trailing-edge at 600ms, so it never did.One recompute at that transition, against N per frame, which is the trade the guard was making anyway. | LinearGenomeView |
coarseVisibleLocStringsstring | same as visibleLocStrings, but only updated every 500ms | LinearGenomeView |
coarseTotalBpDisplayStrstring | LinearGenomeView | |
effectiveTotalBpnumber | LinearGenomeView | |
effectiveTotalBpDisplayStrstring | LinearGenomeView | |
centerLineInfoPxToBpResult | undefined | LinearGenomeView | |
effectiveBodyMountedboolean | Whether this view's body is in the DOM, counting the views it is nested inside — which is the question a display's phase actually asks.bodyMounted alone answers it only for a view a container renders directly. A view nested in another view (a synteny row, a breakpoint panel) has no container writing its flag, so it reads true forever while its whole subtree is out of the DOM, and every display in it waits for a first paint that nothing will make — the hang this flag exists to prevent, one level down.An ancestor that does not carry the flag at all leaves the answer alone rather than excusing the paint: only an explicit false unmounts, so a duck-typed stand-in that forgot it keeps waiting, which is the failure that shows up as a slow test rather than as a picture of an empty view. | BaseViewModel |
Methods
| Member | Description |
|---|---|
trackHeight(track: any) => any | rendered height of a single track, collapsing to a fixed height when minimized. Shared by trackHeights and getTrackYOffset so the two can't disagree. Reads activeDisplay — the display TrackContainer actually mounts — rather than re-picking displays[0], so the view's height math can't diverge from what is on screen. |
getTrackYOffset(trackId: string) => number | undefined | Y offset (in pixels, from the top of the view) where a track's rendering container starts. Walks tracks in DOM render order (pinned first, then unpinned), from the same constants TrackContainer lays its Paper out with. Returns undefined if the track is not present.Exact while track labels are hidden or overlapping. With an offset label the answer is short by one label box per labelled track above this one — see trackChromeHeight for why that box is not derivable here. |
trackSection(id: string) => any[] | the pinned or unpinned sibling list a track renders within; move up/down/top/bottom reorder inside this section rather than the full tracks array, since the two sections lay out independently |
getTrack(id: string) => any | |
getActiveDisplayId(trackId: string) => string | undefined | displayId of the active (shown) display for a track in this view, used by the config editor to expand the relevant display and collapse the track's other displays |
| getSelectedRegions | Helper method for the fetchSequence. Retrieves the corresponding regions that were selected by the rubberband |
exportSvg(opts?: ExportSvgOptions) => Promise<void> | creates an svg export and save using FileSaver |
() => MenuItem[] | return the view menu items |
() => MenuItem[] | what a plugin can start from the selected region — a synteny view, a consensus call. Extend this rather than rubberBandMenuItems so the entries collect under the menu's "Launch" submenu; that grouping is decided once here rather than by whichever contributor runs first, and keeps the rubberband menu itself short as plugins pile on. |
() => MenuItem[] | |
| bpToPx | |
| getHighlightCoords | Map a highlight or bookmark region to its pixel position+width inside the tracks container. Falls back to the raw refName if the region's assemblyName is missing or unknown so highlights authored without an assembly still render in single-assembly views. |
| getOverviewHighlightCoords | like getHighlightCoords but laid out against the overview scalebar and shifted by the cytoband offset |
| centerAt | scrolls the view to center on the given bp. if that is not in any of the displayed regions, does nothing |
pxToBp(px: number) => PxToBpResult | |
(clickOffset: BpOffset) => MenuItem[] | |
(_highlight: HighlightType) => MenuItem[] | returns menu items for a highlight context menu. plugins can extend this via Core-extendPluggableElement to add their own items |
Actions
| Member | Description | Defined by |
|---|---|---|
setShowTrackOutlines(arg: boolean) => void | LinearGenomeView | |
setScrollZoom(flag: boolean) => void | LinearGenomeView | |
setColorByCDS(flag: boolean) => void | LinearGenomeView | |
setShowAminoAcids(flag: boolean) => void | LinearGenomeView | |
setShowCytobands(flag: boolean) => void | LinearGenomeView | |
setWidth(newWidth: number) => void | LinearGenomeView | |
setError(error: unknown) => void | LinearGenomeView | |
(isOpen: boolean) => void | LinearGenomeView | |
setScalebarRefNameClickPending(pending: boolean) => void | LinearGenomeView | |
setHideHeader(b: boolean) => void | LinearGenomeView | |
setHideHeaderOverview(b: boolean) => void | LinearGenomeView | |
setScalebarOnly(b: boolean) => void | LinearGenomeView | |
setHideNoTracksActive(b: boolean) => void | LinearGenomeView | |
setShowGridlines(b: boolean) => void | LinearGenomeView | |
setLabelsVisible(arg: boolean) => void | LinearGenomeView | |
setVolatileGuides(guides: VolatileGuide[]) => void | set temporary vertical guides (e.g., for LD display hover) | LinearGenomeView |
scrollTo(offsetPx: number) => number | LinearGenomeView | |
scrollToBp(startBp: number) => number | scrollTo's bp-space twin: place the window's left edge at a linearized bp coordinate, clamped to the same scroll limits.It exists so a caller that already knows where it wants to be in bp — zoomTo, anchoring the base under the cursor — does not have to convert to pixels and let this convert back. That round trip is lossy once per frame, and a scroll-zoom burst is a few dozen frames, which is enough to walk the base out from under the cursor. | LinearGenomeView |
zoomTo(bpPerPx: number, offset?: any) => number | LinearGenomeView | |
| setOffsets | sets offsets of rubberband, used in the get sequence dialog can call view.getSelectedRegions(view.leftOffset,view.rightOffset) to compute the selected regions from the offsets | LinearGenomeView |
| setSearchResults | LinearGenomeView | |
| showTrack | LinearGenomeView | |
hideTrack(trackId: string) => boolean | LinearGenomeView | |
moveTrackDown(id: string) => void | LinearGenomeView | |
moveTrackUp(id: string) => void | LinearGenomeView | |
moveTrackToTop(id: string) => void | LinearGenomeView | |
moveTrackToBottom(id: string) => void | LinearGenomeView | |
moveTrack(movingId: string, targetId: string) => void | LinearGenomeView | |
toggleTrack(trackId: string) => boolean | LinearGenomeView | |
setTrackLabels(setting: "hidden" | "offset" | "overlapping") => void | LinearGenomeView | |
setShowCenterLine(b: boolean) => void | LinearGenomeView | |
activateTrackSelector() => Widget | LinearGenomeView | |
toggleTrackSelector() => Widget | LinearGenomeView | |
horizontalScroll(distance: number) => number | LinearGenomeView | |
setDraggingTrackId(idx?: string | undefined) => void | LinearGenomeView | |
setLastTrackDragY(y: number) => void | LinearGenomeView | |
onTrackDragOver(targetId: string, currentY: number) => void | called while dragging a track over the track at targetId; reorders once the cursor has moved far enough (see shouldSwapTracks) to avoid jitter when a short track is dragged over a tall one | LinearGenomeView |
setInit(arg?: InitState | undefined) => void | LinearGenomeView | |
slide(viewWidths: number) => void | perform animated slide | LinearGenomeView |
zoom(targetBpPerPx: number) => void | perform animated zoom | LinearGenomeView |
cancelZoomAnimation() => void | cancel an in-flight animated zoom. The animation already yields to any other zoom on its own, so this is for stopping it without changing the zoom — the slider grabbing the thumb, before it has a value to commit. | LinearGenomeView |
setCoarseDynamicBlocks(blocks: BlockSet, bpPerPx: number) => void | LinearGenomeView | |
settleCoarseBlocks() => void | Bring the coarse blocks to the viewport as it stands now, for a placement that JUMPED rather than travelled. The coarse blocks are a 500ms throttle, and every consumer trades freshness for not recomputing per animation frame — the location box, canvas's on-screen feature set, and the two per-bp scans behind settledDynamicBlocks. That trade is only sound while the answer is a few frames old. A jump makes it unrelated instead, because there is nothing to coalesce: the viewport left behind is not an approximation of the new one, it is a different place. Unsettled, the location box reads as a navigation that didn't happen, and wiggle's autoscale domain is computed over the window the user just left — measured at [0,200] against a correct [0,300] when a 40bp coarse window survived a jump to 4040bp on screen. Only the per-region fetch moving to the leading edge made that reachable: at 600ms the data never landed inside the hole.The continuous paths deliberately do not come through here. The spring zoom writes through zoomTo per frame and a drag through scrollTo, so this adds no per-frame work; the settle is idempotent (setCoarseDynamicBlocks compares block keys), so the debounced autorun's own follow-up run costs nothing.Every placer calls it, and placersSettleCoarseBlocks.test.ts is what makes that true of the next one — it scans this file for the writes and fails on a placer that reaches neither the settle nor its named list of continuous paths. Two passes by hand missed four. | LinearGenomeView |
| moveTo | offset is the base-pair-offset in the displayed region, index is the index of the displayed region in the linear genome view | LinearGenomeView |
setNewView(bpPerPx: number, offsetPx: number) => void | Place the viewport by the pair of PIXEL quantities it used to be stored as. Prefer setWindow: pixels mean nothing without the width they were measured at, so a round trip through here is only exact while the width holds still. Kept for callers that genuinely have pixels — a wheel gesture, a rubberband — and for reading old snapshots. | LinearGenomeView |
setWindow(windowWidthBp: number, windowStartBp: number) => void | Place the viewport by the pair it is actually STORED as: the window's width and left edge, both in bp. setNewView's bp-space twin, and the right one for anything that captures a viewport and puts it back later (an Undo, a saved location) — those two moments can be a window resize apart, and this pair survives one where a pixel pair does not.Still clamped, by the same zoom and scroll limits as every other mover: the regions may have changed under it, and a window the new set can't hold is not restorable however it was spelled. | LinearGenomeView |
setWindowFrame(windowWidthBp: number, windowStartBp: number) => void | setWindow without the settle, for a writer that runs per animation frame. Flushing the coarse blocks sixty times a second is the one thing such a writer must not do: they are a 500ms throttle that a synteny follow pass and two autoscale domains hang off, and settling each frame turns each of those into per-frame work — positionViewOnSpans states the same rule for the same reason. | LinearGenomeView |
setDisplayedRegions(regions: Region[]) => void | The worst jump of them to leave unsettled: the coarse blocks are keyed by displayedRegionIndex, so a set that outlives the region list has a consumer reading one contig's data against another's blocks. | LinearGenomeView |
clampZoomToCeiling() => void | Re-assert maxBpPerPx over the current zoom, for a container whose shared ceiling just fell — otherwise the view is stranded above it with zoom-out disabled and the slider's min past its value. Goes through zoomTo so the clamp keeps one definition, and settles because a ceiling drop moves the window in one step.Requires an initialized view; the caller checks, since an MST action reads untracked and a guard here would never re-run once the row arrived. | LinearGenomeView |
showAllRegions() => void | LinearGenomeView | |
fitAllRegions() => void | Fit the displayed regions to the width exactly, edge to edge. Not the same as showAllRegions, which goes to maxBpPerPx — the zoom-out LIMIT, where SHOW_ALL_REGIONS_FILL deliberately keeps a 10% margin so the whole genome doesn't sit flush against both edges. That margin is right for "show me everything" and wrong for a caller that named the regions it wants: it draws them at 1/0.9 of fit-to-width, centered, which is a silent 11% scale difference from the single-region path (moveTo, span/width) reached through the same location box.The scale comes from fitAllRegionsWindow, which is where the rule is written — a snapshot builder that cannot call an action needs the same answer, and the two agreeing matters more than either being local. Where it clamps up to minBpPerPx the content is narrower than the view, and the centering is what frames it. | LinearGenomeView |
horizontallyFlip() => void | LinearGenomeView | |
showAllRegionsInAssembly(assemblyName?: string | undefined) => void | LinearGenomeView | |
clearView() => void | this "clears the view" and makes the view return to the import form | LinearGenomeView |
(query: NavLocation, grow?: number | undefined) => void | Navigate to a location based on its refName and optionally start, end, and assemblyName. Will not try to change displayed regions, use navToLocations instead. Only navigates to a location if it is entirely within a displayedRegion. Navigates to the first matching location encountered.Throws an error if navigation was unsuccessful | LinearGenomeView |
(locations: NavLocation[], grow?: number | undefined) => void | Navigate to a location based on its refName and optionally start, end, and assemblyName. Will not try to change displayed regions, use navToLocations instead. Only navigates to a location if it is entirely within a displayedRegion. Navigates to the first matching location encountered. Throws an error if navigation was unsuccessful | LinearGenomeView |
showRegions(regions: Region[], location?: NavLocation | undefined) => void | Replace the region list and place the viewport in one step. The pair is the unit a coarse-block consumer can act on: called separately they publish the viewport in between, and post-await in navToLocations they are two transactions, so a per-bp scan runs over a window that was never on screen.With no location named it fits the regions rather than going through showAllRegions: the caller named the regions it wants, so it gets the width, where showAllRegions goes to the zoom-out LIMIT and its 10% margin is dead frame for a named subset. | LinearGenomeView |
| Navigate to the given locstring, will change displayed regions if needed, and wait for assemblies to be initialized | LinearGenomeView | |
Similar to navToLocString, but accepts a list of parsed location objects instead of a locstring. Will try to perform setDisplayedRegions if changing regions | LinearGenomeView | |
Similar to navToLocString, but accepts a parsed location object instead of a locstring. Will try to perform setDisplayedRegions if changing regions | LinearGenomeView | |
flyTo(centerBp: number, windowWidthBp: number) => void | Travel to a window rather than appear in it: the Van Wijk arc from where the view is to where it is going, played over its own duration. WHAT LANDS IS WHAT setWindow WOULD HAVE LANDED — only the path in between is new. That is what lets a caller offer an Undo, a snackbar or a follow anchor around this exactly as it did around the instant move.It YIELDS to anything else that moves the view, by reading back what it wrote and stopping the moment the view holds something else: a wheel zoom, a drag, a locstring nav, or the Undo on the very snackbar the flight was launched with. Compared against what was WRITTEN rather than what was asked for, because the write clamps — an arc that pulls back past maxBpPerPx reads its own clamped result back, and treating that as interference would end the flight one frame in. springAnimate defends the same value the same way. | LinearGenomeView |
flyToCenter(coord: number, refName: string) => void | centerAt's animated twin: the same destination, reached along the arc instead of jumped to, at the zoom the view is already on. | LinearGenomeView |
setDisplayName(name: string) => void | BaseViewModel | |
setBodyMounted(flag: boolean) => void | See bodyMounted. Written by the view's container, which is the only thing that knows whether it rendered the body. | BaseViewModel |
setMinimized(flag: boolean) => void | BaseViewModel | |
addToHighlights(highlight: HighlightType) => void | HighlightsMixin | |
setHighlight(highlight?: HighlightType[] | undefined) => void | HighlightsMixin | |
removeHighlight(highlight: HighlightType) => void | HighlightsMixin | |
updateHighlight(old: HighlightType, updates: Partial<HighlightType>) => void | HighlightsMixin | |
setShowHighlightChips(arg: boolean) => void | HighlightsMixin |
Related links
- Guide: Embedded components
- Guide: URL query parameter API