ohif-viewer/docs/latest/extensions/index.md

Extensions

• Overview
• Concepts
  • Extension Skeleton
  • Registering an Extension
  • Lifecylce Hooks
  • Modules
  • Contexts
• Consuming Extensions
• Maintained Extensions

Overview

We use extensions to help us isolate and package groups of related features. Extensions provide functionality, ui components, and new behaviors.

Diagram showing how extensions are configured and accessed.

The @ohif/viewer's application level configuration gives us the ability to add and configure extensions. When the application starts, extensions are registered with the ExtensionManager. Different portions of the @ohif/viewer project will use registered extensions to influence application behavior.

Extensions allow us to:

• Wrap and integrate functionality of 3rd party dependencies in a reusable way
• Change how application data is mapped and transformed
• Display a consistent/cohesive UI
• Inject custom components to override built-in components

Practical examples of extensions include:

• A set of segmentation tools that build on top of the cornerstone viewport
• Showing ML/AI report summaries for the selected study/series/image
• Support for parsing DICOM structured reports and displaying them in a user friendly way
• See our maintained extensions for more examples of what's possible

Concepts

Extension Skeleton

An extension is a plain JavaScript object has an id property, and one or more "getModuleFunctions" and/or lifecycle hooks. You can read more about lifecycle hooks and modules further down.

// prettier-ignore
export default {
  /**
   * Only required property. Should be a unique value across all extensions.
   */
  id: 'example-extension',

  // Lifecyle
  preRegistration() { /* */ },
  // Modules
  getCommandsModule() { /* */ },
  getToolbarModule() { /* */ },
  getPanelModule() { /* */ },
  getSopClassHandler() { /* */ },
  getViewportModule() { /* */ },
}

Registering an Extension

There are two different ways to register and configure extensions. You can leverage one or both strategies. Which one(s) you choose depend on your application's requirements. Each module defined by the extension becomes available to the core application via the ExtensionManager.

// prettier-ignore
const config = {
  extensions: [
    MyFirstExtension,
    [
      MySecondExtension,
      { /* MySecondExtensions Configuration */ },
    ],
  ];
}

Runtime Extensions

The @ohif/viewer uses a configuration file at startup. The schema for that file includes an Extensions key that supports an array of extensions to register.

Bundled Extensions

The @ohif/viewer works best when built as a "Progressive Web Application" (PWA). If you know the extensions your application will need, you can specify them at "build time" to leverage some advantaged afforded to us by modern tooling:

• Code Splitting
• Tree Shaking
• Dependency deduplication

You can update the list of bundled extensions by:

1. Having your @ohif/viewer project depend on the extension
2. Importing and adding it to the list of extensions in the <repo-root>/platform/src/index.js entrypoint.

Lifecycle Hooks

...

Modules

There are a few different module types. Each module type allows us to extend the viewer in a different way, and provides a consistent API for us to do so. You can find a full list of the different types of modules in ohif-core. Information on each type of module, it's API, and how we determine when/where it should be used is included below.

Contexts

...

Consuming Extensions

...

Maintained Extensions

A small number of powerful extensions for popular use cases are maintained by OHIF. They're co-located in the OHIF/Viewers repository, in the top level extensions/ directory.

{% include "./_maintained-extensions-table.md" %}