MultipleViewsSessionMixin

Auto-generated from the @jbrowse/mobx-state-tree model in the source — see the developer guide for concepts. Built into JBrowse core. View source.

Adds a list of views to a session, with actions to add, remove, replace and reorder them.

Each section ends with the members a composed model contributes, linked to the page that documents them.

Properties

Member	Description
views `views: types.array( pluginManager.pluggableMstType('view', 'stateModel'), )`
stickyViewHeaders `stickyViewHeaders: types.optional(types.boolean, () => localStorageGetBoolean('stickyViewHeaders', true), )`

12 inherited properties from 2 models

From BaseSessionModel: id, name, focusedViewId, highlights, highlightsVisible, highlightLabelsVisible, heldForMissingPlugins

From DrawerWidgetSessionMixin: drawerPosition, drawerWidth, widgets, activeWidgets, minimized

Volatiles

8 inherited volatiles from 3 models

From BaseSessionModel: selection, hovered, queueOfDialogs, preferencesOverrides

From SnackbarModel: snackbarMessages, errorDialog

From DrawerWidgetSessionMixin: poppedOut, modalWidgets

Getters

16 inherited getters from 3 models

From BaseSessionModel: root, jbrowse, rpcManager, configuration, adminMode, textSearchManager, assemblies, DialogComponent, DialogProps, animationMode, scrollZoom, numberGrouping

From SnackbarModel: snackbarMessageSet

From DrawerWidgetSessionMixin: visibleWidget, drawerVisible, modalWidgetVisible

Methods

3 inherited methods from one model

From BaseSessionModel: getPreferenceDefault, getPreference, getPreferenceChanges

Actions

Member	Description
moveViewDown `(id: string, scopeIds?: string[] \| undefined) => void`
moveViewUp `(id: string, scopeIds?: string[] \| undefined) => void`
moveViewToTop `(id: string, scopeIds?: string[] \| undefined) => void`
moveViewToBottom `(id: string, scopeIds?: string[] \| undefined) => void`
orderViews `(ids: string[]) => void`	Put the named views into the given relative order, leaving views not named in their own slots. `session.views` is the one ordering, so this is how a channel that states an order in some other vocabulary gets it applied: a session spec's `layout` names views per panel, top to bottom, and that used to be honoured by the panel assignment array's order. Now the assignment carries membership only, so the layout says it here instead, once.
addView `<N extends string>(typeName: N, initialState?: NoInfer<ViewSnapshotInput<N>> \| undefined) => any`	Requires the view type's state model to be loaded; for a lazily registered type use `launchView`.
replaceView `<N extends string>(view: IBaseViewModel, typeName: N, initialState?: NoInfer<ViewSnapshotInput<N>> \| undefined) => any`	swap `view` for a new view of `typeName`, in the slot it occupied. The launchers that build a view of a DIFFERENT type out of one you are already looking at — launch synteny view, read-vs-ref, split view — otherwise append, leaving the source view above the thing it produced and a stack of two views showing the same locus. This is the "replace" half of that offer, and a slot swap rather than remove-then-add so the new view lands where the reader was looking instead of at the bottom of the session. A launcher whose result is the SAME type as its source does not come here and should not: collapse introns offers "Replace current view" by navigating the view it was invoked on, which keeps the view's identity and so lets its snackbar offer an Undo. Swapping in a new node would leave nothing to undo onto. The slot is `session.views`, which is the order views render in under both layout modes (a tab's `viewIds` says which tab a view is in, not where in it), so the swap lands in place either way. WHICH panel is a separate question and this does not answer it: the new view arrives in no tab, and `homeUnassignedViews` puts it in the active panel — the same panel only when the replaced view was in the active one. In practice it is, since clicking into a view activates its panel, and the launch that offers a replace is a click on that view's own menu.
removeView `(view: IBaseViewModel) => void`
takeOutViewsMissingFrom `(snapshot: unknown) => void`	Take out every view the given session snapshot will not keep, before a whole-tree `applySnapshot` destroys it where it stands. Undo and redo are `applySnapshot` on the session (`core/util/TimeTraveller`, which calls this), and every view carries an `ElementId` — so MST reconciles by identifier and destroys what the target lacks, inside the action, with the components still mounted. Measured on a redo across a closed view, with the restored view repainted first: 4 liveliness reads of its display before this, 0 after. A view that is present but has changed `type` is destroyed by that same reconciliation (`areSame` runs the type's `is()` before its id check), so identity here is the pair, not the id. Views, and deliberately not what is under them. A track or a display the snapshot drops is still destroyed in place, and that is not this door being worse than the others: `hideTrackGeneric` is a plain `tracks.remove` and measures louder (5 reads to undo's 4). Detaching one would be worse than the destroy it replaced — a detached display is a LIVE root, and `getContainingView` walks parents and throws when the walk finds no view, where a dead node only warns. At or above the view is the only place that walk still lands, which is why ADR-069's rule stops there.
setStickyViewHeaders `(sticky: boolean) => void`
setUseWorkspaces `(_useWorkspaces?: boolean \| undefined) => void`	Does nothing: the workspace is always on. Kept because published protein3d and msaview bundles call it after placing a view.
launchView `<N extends string>(typeName: N, initialState?: NoInfer<ViewSnapshotInput<N>> \| undefined) => Promise<any>`	`addView` for view types whose state model may be lazily loaded. The view is not in `session.views` until the promise resolves. `getViewType` first so an unknown type name fails by that name; the snapshot walk skips unregistered names and covers the displays of the tracks a launch opens with.