Skip to main content
When you embed the chat widget and document viewer widget on the same page, you can pass both widgets a single BigdataWidgetManager. The manager gives you one place for base theming and a shared event path so when the chat raises opendocument (for example from a citation), the document viewer can show that document without wiring your own pub/sub or global state.

​
Connecting Bigdata widgets

Load both widget script tags first so BigdataAgent and BigdataDocumentViewer are defined. Then create one BigdataWidgetManager and pass it in each widget’s config along with distinct instanceId values.
BigdataWidgetManager may be exposed by more than one widget bundle (for example the chat and document viewer). In this guide we use the canonical UMD export on BigdataDocumentViewer: BigdataDocumentViewer.BigdataWidgetManager. Use either export consistently-don’t mix them in the same page’s code.
The proxy, API keys, and CORS story are unchanged. Each widget may still use its own proxyUrl; see the two embed guides for your backend and Research Agent API and document Content flows.

​
How a citation reaches the document viewer

Citation flow - the chat emits opendocument on the shared BigdataWidgetManager; the manager delivers it to the document viewer, which opens the file. Event payloads in handlers include instanceName, timestamp, and data. The data object matches the chat and document viewer event tables.

​
Minimal wiring (concept)

  1. Create a manager -
new BigdataDocumentViewer.BigdataWidgetManager(
  { theme: { /* optional, shared base */ } }
)
The class is exposed on the UMD object BigdataDocumentViewer; see the Global API: BigdataDocumentViewer section in the document viewer page.
  1. Initialize the document viewer -
new BigdataDocumentViewer.BigdataDocumentWidget({
  container,
  proxyUrl,
  manager,
  instanceId: "my-document",
  /* openDocument, getHeaders, theme, … */
})
  1. Initialize the chat -
new BigdataAgent.BigdataChatWidget(
  {
    container,
    proxyUrl,
    manager,
    instanceId: "my-chat",
    /* config, theme, … */
  }
)
Use a string instanceId for each that is unique on the page. If you omit it, the defaults are "chat" and "document", which is fine for a single pair. Add explicit ids if you add more than one of either widget or want clearer logs and listeners. Example shape (placeholders; align script URLs and options with the two quickstarts): 
<div id="document-widget" style="min-height: 400px; width: 100%;"></div>

<div id="chat-widget" style="min-height: 520px; width: 100%; margin-top: 1rem;"></div>

<script>
  (function() {
    var manager = new BigdataDocumentViewer.BigdataWidgetManager({
      theme: { preset: "auto" },
    });

    new BigdataDocumentViewer.BigdataDocumentWidget({
      container: "#document-widget",
      proxyUrl: "https://your.api.example.com/document-proxy",
      manager: manager,
      instanceId: "my-document",
    });

    new BigdataAgent.BigdataChatWidget({
      container: "#chat-widget",
      proxyUrl: "https://your.api.example.com/chat-proxy",
      manager: manager,
      instanceId: "my-chat",
    });
  })();
</script>
(Requires both widget bundles loaded before this inline block.)

​
Sharing configuration through the manager

  • Base theme - The manager holds an optional shared baseTheme. The widgets merge their own theme on top, same as in Multiple widgets and shared theming (chat) and the document viewer’s matching section.
  • Event bus - Internally, when one widget emits an event, the manager broadcasts it to every instance registered on that manager. The document viewer listens for opendocument to switch what is on screen. The chat emits that event when a user follows a Bigdata citation, so a shared manager is how those two stay in sync on one page.

​
Events you lean on for coordination

EventRole when connecting the two widgets
opendocumentChat emits with data: at least documentId, isPrivate; optional match metadata for highlights when your integration supplies it. The document viewer handles the event to show the file. Full field lists: Chat · Document
openlinkFor opening an external URL instead of in-product document navigation; chat describes the data shape.
readyFires with { widgetName } after the widget is mounted.
You can still use addListener / removeListener (or the chat’s emit for advanced flows such as a host-triggered send - see the chat page) on the returned instances the same as on a single widget.

​
Build your own connection

The chat can register onDocumentClick and onLinkClick in config (or attach equivalent listeners on the chat instance). These are shortcuts for observing user interactions (analytics, logging, or side effects) and do not override the default built-in behavior by themselves. The usual “chat + document on one page” path is the shared manager: the chat emits, the document viewer is already listening through the same manager, so you do not need extra glue for the default “open in viewer” experience.

​
Further reading

  • Chat widget - proxyUrl, config, themes, and events.
  • Document viewer - openDocument shape, proxy contract, and events.
  • Support - for WordPress, enterprise questions, or integration help.