---
id: events
title: JBrowse Subscribe/Publish events
---


There are two layers of events, ''internal'' ones used by JBrowse
plugins and components to communicate among themselves, and
''external'' ones used by other software to communicate with JBrowse.

    external  <->  controller  <->  views

## External

### Commands

    /jbrowse/v1/cmd/*

### Notifications

    /jbrowse/v1/notify/*

##Internal

Internal events are named for where they originate.

`/jbrowse/v1/v`: messages from views, mostly notifying other components
of what logical commands the user is issuing through her actions with
the view.

`/jbrowse/v1/c`: messages from controllers, such as requests to turn
on certain tracks, highlight certain features, and so forth.


## Milestone functions

The previous section covered the afterMilestone function for waiting on certain tasks to be finished during initialization

Other milestones include:

-   initPlugins - plugins loaded. note: plugins can be loaded before everything else is finished, so plugins may use these milestone functions in their own code
-   loadUserCSS - user CSS loaded
-   loadRefSeqs - reference sequence json or data is loaded
-   loadNames - names store loaded
-   initView - view initialized
-   loadConfig - configurations loaded
-   initTrackMetadata - track metadata loaded
-   createTrack - when track list finished initializing
-   completely initialized - all milestones passed. note the space in the milestone name

## Publishing and Subscribing to JBrowse Events

JBrowse client events are implemented using the dojo/topic message bus from the Dojo library. Extensions can subscribe to particular events in order to be notified when certain UI changes happen (for example, highlighting a region generates an event, which can be latched onto with a callback that triggers a request for the server to BLAST that region against a database). In select cases, extensions can also publish events, as a way of forcing the UI into certain states or transitions (for example, events can be used in this way to force the browser to load a new track, in response to some other circumstance or notification).

When events are associated with tracks, the event names take the form `/jbrowse/v1/{type}/tracks/{trackEvent}`. The `{type}` is one of ‘`v`’, ‘`c`’, or ‘`n`’, corresponding to view events (requests from the user, handled by the browser); command events (which trigger actions in the UI, and are often generated by the browser in response to view events); or notification events (informing subscribers that something just happened). The `{trackEvent}` specifies the nature of the track event and is one of ‘`new`’, ‘`delete`’, ‘`show`’, ‘`hide`’, ‘`pin`’, ‘`unpin`’, ‘`replace`’, ‘`redraw`’, or ‘`visibleChanged`’.

When events are global, the event names take the form `/jbrowse/v1/{type}/{globalEvent}` where `{type}` is as above and `{globalEvent}` is one of ‘`navigate`’ or ‘`globalHighlightChanged`’.

The DebugEvents plugin logs events to the console, and can be used to monitor events as they are triggered by user interactions with the browser.

Note that you can also publish and subscribe to a JBrowse instance that is in an iframe. See <http://gmod.org/wiki/JBrowse_FAQ#How_can_I_get_jbrowse_to_update_the_URL_of_a_parent_page_when_jbrowse_is_inside_of_an_iframe> for an example


