chore: Clean up unused files, imports, and work on getting end-to-end tests and unit tests running (#2272)

.circleci/config.yml

@@ -13,11 +13,23 @@ version: 2.1
 ##
 orbs:
   codecov: codecov/codecov@1.0.5
-  cypress: cypress-io/cypress@1.13.0
+  cypress: cypress-io/cypress@1.26.0
+executors:
+  # Custom executor to override Cypress config
+  deploy-to-prod-executor:
+    docker:
+      - image: 'cypress/browsers:node14.15.0-chrome86-ff82'
+        environment:
+          CYPRESS_BASE_URL: https://ohif-staging.netlify.com/
+  chrome-and-pacs:
+    docker:
+      # Primary container image where all steps run.
+      - image: 'cypress/browsers:node14.15.0-chrome86-ff82'
+      - image: 'ohif/viewer-testdata:0.1-test'
 
 defaults: &defaults
   docker:
-    - image: circleci/node:12.9.1
+    - image: circleci/node:14.15.0
       environment:
         TERM: xterm # Enable colors in term
         QUICK_BUILD: true
@@ -170,7 +182,7 @@ jobs:
 
   DEPLOY_TO_DEV:
     docker:
-      - image: circleci/node:12.9.1
+      - image: circleci/node:14.15.0
         environment:
           TERM: xterm
           NETLIFY_SITE_ID: 32708787-c9b0-4634-b50f-7ca41952da77
@@ -185,7 +197,7 @@ jobs:
 
   DEPLOY_TO_STAGING:
     docker:
-      - image: circleci/node:12.9.1
+      - image: circleci/node:14.15.0
         environment:
           TERM: xterm
           NETLIFY_SITE_ID: c7502ae3-b150-493c-8422-05701e44a969
@@ -200,7 +212,7 @@ jobs:
 
   DEPLOY_TO_PRODUCTION:
     docker:
-      - image: circleci/node:12.9.1
+      - image: circleci/node:14.15.0
         environment:
           TERM: xterm
           NETLIFY_SITE_ID: 79c4a5da-5c95-4dc9-84f7-45fd9dfe21b0
@@ -307,8 +319,73 @@ jobs:
 workflows:
   version: 2
 
-  # WORKFLOWS Disabled until this feature branch is further along
-  # See Master's CircleCI Config
+  PR_CHECKS:
+    jobs:
+      - UNIT_TESTS:
+          filters:
+            branches:
+              ignore:
+                - master
+                - feature/*
+                - hotfix/*
+      # E2E: PWA
+      - cypress/run:
+          name: 'E2E: PWA'
+          executor: chrome-and-pacs
+          browser: chrome
+          pre-steps:
+            - run: |
+                # Clear yarn cache; update to latest
+                rm -rf ~/.yarn
+                npm i -g yarn
+                yarn -v
+          yarn: true
+          record: true
+          store_artifacts: true
+          working_directory: platform/viewer
+          build: npx cross-env QUICK_BUILD=true APP_CONFIG=config/dicomweb-server.js yarn run build
+          start: yarn run test:e2e:serve
+          spec: 'cypress/integration/**/*'
+          wait-on: 'http://localhost:3000'
+          cache-key: 'yarn-packages-{{ checksum "yarn.lock" }}'
+          no-workspace: true # Don't persist workspace
+          post-steps:
+            - store_artifacts:
+                path: platform/viewer/cypress/screenshots
+            - store_artifacts:
+                path: platform/viewer/cypress/videos
+            - store_test_results:
+                path: platform/viewer/cypress/results
+          requires:
+            - UNIT_TESTS
+
+  PR_OPTIONAL_VISUAL_TESTS:
+    jobs:
+      - AWAIT_APPROVAL:
+          type: approval
+      # Update hub.docker.org
+      - cypress/run:
+          name: 'Generate Percy Snapshots'
+          executor: cypress/browsers-chrome76
+          browser: chrome
+          pre-steps:
+            - run: 'rm -rf ~/.yarn && npm i -g yarn && yarn -v && yarn global
+                add wait-on' # Use yarn latest
+          yarn: true
+          store_artifacts: false
+          working_directory: platform/viewer
+          build: npx cross-env QUICK_BUILD=true APP_CONFIG=config/dicomweb-server.js yarn run build
+          # start server --> verify running --> percy + chrome + cypress
+          command: yarn run test:e2e:dist
+          cache-key: 'yarn-packages-{{ checksum "yarn.lock" }}'
+          no-workspace: true # Don't persist workspace
+          post-steps:
+            - store_artifacts:
+                path: platform/viewer/cypress/screenshots
+            - store_artifacts:
+                path: platform/viewer/cypress/videos
+          requires:
+            - AWAIT_APPROVAL
 
   DEPLOY:
     jobs:
@@ -319,3 +396,61 @@ workflows:
       - DEPLOY_TO_DEV:
           requires:
             - BUILD
+      - PROMOTE_TO_STAGING:
+          type: approval
+          requires:
+            - DEPLOY_TO_DEV
+      - DEPLOY_TO_STAGING:
+          requires:
+            - PROMOTE_TO_STAGING
+      - PROMOTE_TO_PRODUCTION:
+          type: approval
+          requires:
+            - DEPLOY_TO_STAGING
+      - DEPLOY_TO_PRODUCTION:
+          requires:
+            - PROMOTE_TO_PRODUCTION
+  ###
+  # Unit and E2E tests have already run for PR_CHECKS
+  # Re-running should not gain us any confidence here
+  ###
+  RELEASE:
+    jobs:
+      - NPM_PUBLISH:
+          filters:
+            branches:
+              only: master
+      - DOCS_PUBLISH:
+          filters:
+            branches:
+              only: master
+      # Update base branch snapshots
+      # and record a Cypress dashboard test run
+      - cypress/run:
+          name: 'Generate Percy Snapshots'
+          executor: cypress/browsers-chrome76
+          browser: chrome
+          pre-steps:
+            - run: 'rm -rf ~/.yarn && npm i -g yarn && yarn -v && yarn global
+                add wait-on' # Use yarn latest
+          yarn: true
+          store_artifacts: false
+          working_directory: platform/viewer
+          build: npx cross-env QUICK_BUILD=true APP_CONFIG=config/dicomweb-server.js yarn run build
+          # start server --> verify running --> percy + chrome + cypress
+          command: yarn run test:e2e:dist
+          cache-key: 'yarn-packages-{{ checksum "yarn.lock" }}'
+          no-workspace: true # Don't persist workspace
+          post-steps:
+            - store_artifacts:
+                path: platform/viewer/cypress/screenshots
+            - store_artifacts:
+                path: platform/viewer/cypress/videos
+            - store_test_results:
+                path: platform/viewer/cypress/results
+          filters:
+            branches:
+              only: master
+      - DOCKER_MASTER_PUBLISH:
+          requires:
+            - NPM_PUBLISH

.eslintrc.json

@@ -16,7 +16,8 @@
   },
   "rules": {
     "react/jsx-props-no-spreading": "error",
-    "react-hooks/exhaustive-deps": "false"
+    "react-hooks/exhaustive-deps": "false",
+    "import/no-unused-modules": [1, {"unusedExports": true}]
   },
   "globals": {
     "cy": true,

.vscode/extensions.json

@@ -1,7 +1,6 @@
 {
   "recommendations": [
     "esbenp.prettier-vscode",
-    "sysoev.language-stylus",
     "dbaeumer.vscode-eslint",
     "mikestead.dotenv",
     "bungcip.better-toml",

.webpack/rules/stylusToJavaScript.js

@@ -1,10 +0,0 @@
-const stylusToJavaScript = {
-  test: /\.styl$/,
-  use: [
-    { loader: 'style-loader' }, // 3. Style nodes from JS Strings
-    { loader: 'css-loader' }, // 2. CSS to CommonJS
-    { loader: 'stylus-loader' }, // 1. Stylus to CSS
-  ],
-};
-
-module.exports = stylusToJavaScript;

.webpack/webpack.base.js

@@ -14,6 +14,7 @@ const TerserJSPlugin = require('terser-webpack-plugin');
 const NODE_ENV = process.env.NODE_ENV;
 const QUICK_BUILD = process.env.QUICK_BUILD;
 const BUILD_NUM = process.env.CIRCLE_BUILD_NUM || '0';
+const { UnusedFilesWebpackPlugin } = require("unused-files-webpack-plugin");
 
 //
 dotenv.config();
@@ -99,6 +100,18 @@ module.exports = (env, argv, { SRC_DIR, DIST_DIR }) => {
           process.env.LOCIZE_API_KEY || ''
         ),
       }),
+      new UnusedFilesWebpackPlugin({
+        failOnUnused: true,
+        globOptions: {
+          ignore: [
+            "node_modules/**/*",
+            "index.umd.js",
+            "sanity.test.js",
+            "__mocks__/fileMock.js",
+            "__tests__/globalSetup.js"
+          ]
+        }
+      }),
     ],
     // Fix: https://github.com/webpack-contrib/css-loader/issues/447#issuecomment-285598881
     // For issue in cornerstone-wado-image-loader

.webpack/webpack.commonjs.js

@@ -1,19 +0,0 @@
-const merge = require('webpack-merge');
-const webpackBase = require('./webpack.base.js');
-const cssToJavaScriptRule = require('./rules/cssToJavaScript.js');
-const stylusToJavaScriptRule = require('./rules/stylusToJavaScript.js');
-
-/**
- * WebPack configuration for CommonJS Bundles. Extends rules of BaseConfig by making
- * sure we're bundling styles and other files that would normally be split in a
- * PWA.
- */
-module.exports = (env, argv, { SRC_DIR, DIST_DIR }) => {
-  const baseConfig = webpackBase(env, argv, { SRC_DIR, DIST_DIR });
-
-  return merge(baseConfig, {
-    module: {
-      rules: [cssToJavaScriptRule, stylusToJavaScriptRule],
-    },
-  });
-};

README.md

@@ -173,9 +173,7 @@ also supports a number of commands that can be found in their respective
 | `dev:project <package-name>` | Replace with `core`, `ui`, `i18n`, `cornerstone`, `vtk`, etc. |
 | `test:unit`                  | Jest multi-project test runner; overall coverage              |
 | **Deploy**                   |                                                               |
-| `build`\*                    | Builds production output for our PWA Viewer                   |
-| `build:package`\*            | Builds production `commonjs` output for our Viewer            |
-| `build:package-all`\*        | Builds commonjs bundles for all projects                      |
+| `build`\*                    | Builds production output for our PWA Viewer                   |                      |
 
 \* - For more information on our different builds, check out our [Deploy
 Docs][deployment-docs]
@@ -189,24 +187,27 @@ you'll see the following:
 
 ```bash
 .
-├── extensions              #
-│   ├── _example            # Skeleton of example extension
-│   ├── cornerstone         # 2D images w/ Cornerstone.js
-│   ├── dicom-html          # Structured Reports as HTML in viewport
-│   ├── dicom-microscopy    # Whole slide microscopy viewing
-│   ├── dicom-pdf           # View DICOM wrapped PDFs in viewport
-│   └── vtk                 # MPR and Volume support w/ VTK.js
+├── extensions               #
+│   ├── _example             # Skeleton of example extension
+│   ├── default              #  
+│   ├── cornerstone          # 2D images w/ Cornerstone.js
+│   ├── dicom-sr             # 
+│   └── measurement-tracking # 
 │
-├── platform                #
-│   ├── core                # Business Logic
-│   ├── i18n                # Internationalization Support
-│   ├── ui                  # React component library
-│   └── viewer              # Connects platform and extension projects
+├── modes                    #
+│   ├── _example             # Skeleton of example mode
+│   └── longitudinal         #  
 │
-├── ...                     # misc. shared configuration
-├── lerna.json              # MonoRepo (Lerna) settings
-├── package.json            # Shared devDependencies and commands
-└── README.md               # This file
+├── platform                 #
+│   ├── core                 # Business Logic
+│   ├── i18n                 # Internationalization Support
+│   ├── ui                   # React component library
+│   └── viewer               # Connects platform and extension projects
+│
+├── ...                      # misc. shared configuration
+├── lerna.json               # MonoRepo (Lerna) settings
+├── package.json             # Shared devDependencies and commands
+└── README.md                # This file
 ```
 
 Want to better understand why and how we've structured this repository? Read
@@ -231,11 +232,7 @@ can [read more about extensions here][ohif-extensions].
 
 | Name                                                           | Description                                             | Links                  |
 | -------------------------------------------------------------- | ------------------------------------------------------- | ---------------------- |
-| [@ohif/extension-cornestone][extension-cornerstone]            | 2D image viewing, annotation, and segementation tools   | [NPM][cornerstone-npm] |
-| [@ohif/extension-dicom-html][extension-dicom-html]             | Support for viewing DICOM SR as rendered HTML           | [NPM][html-npm]        |
-| [@ohif/extension-dicom-microscopy][extension-dicom-microscopy] | Whole slide microscopy viewing                          | [NPM][microscopy-npm]  |
-| [@ohif/extension-dicom-pdf][extension-dicom-pdf]               | View DICOM wrapped PDFs in a viewport                   | [NPM][pdf-npm]         |
-| [@ohif/extension-vtk][extension-vtk]                           | Volume rendering, reconstruction, and 3D visualizations | [NPM][vtk-npm]         |
+| [@ohif/extension-cornerstone][extension-cornerstone]            | 2D image viewing, annotation, and segementation tools   | [NPM][cornerstone-npm] |
 
 ## Acknowledgments
 

babel.config.js

@@ -44,20 +44,3 @@ module.exports = {
     },
   },
 };
-
-// TODO: Plugins; Aliases
-// We don't currently use aliases, but this is a nice snippet that would help
-// [
-//   'module-resolver',
-//   {
-//     // https://github.com/tleunen/babel-plugin-module-resolver/issues/338
-//     // There seem to be a bug with module-resolver with a mono-repo setup:
-//     // It doesn't resolve paths correctly when using root/alias combo, so we
-//     // use this function instead.
-//     resolvePath(sourcePath, currentFile, opts) {
-//       // This will return undefined if aliases has no key for the sourcePath,
-//       // in which case module-resolver will fallback on its default behaviour.
-//       return aliases[sourcePath];
-//     },
-//   },
-// ],

docs/latest/book.json

@@ -34,8 +34,12 @@
           "text": "Version 1.0.0 (Meteor)"
         },
         {
-          "value": "https://docs.ohif.org/",
+          "value": "https://docs.ohif.org/history/v2/",
           "text": "Version 2.0.0",
+        },
+        {
+          "value": "https://docs.ohif.org/",
+          "text": "Version 3.0.0",
           "selected": true
         }
       ]

docs/v1/book.json

@@ -35,8 +35,12 @@
           "selected": true
         },
         {
-          "value": "https://docs.ohif.org/",
+          "value": "https://docs.ohif.org/history/v2/",
           "text": "Version 2.0.0"
+        },
+        {
+          "value": "https://docs.ohif.org/",
+          "text": "Version 3.0.0"
         }
       ]
     }

docs/v2/README.md

@@ -0,0 +1,54 @@
+<div class='row'>
+	<div class='column' style='text-align: right; padding: 0 20px'>
+		<strong>Looking for a Live Demo?</strong>
+		<a href="http://viewer.ohif.org/">Preview The OHIF Viewer</a>
+	</div>
+	<div class='column' style='text-align: left; padding: 0 20px'>
+		<a href="https://www.netlify.com">
+		  <img src="https://www.netlify.com/img/global/badges/netlify-color-bg.svg"/>
+		</a>
+	</div>
+</div>
+
+> ATTENTION! You are looking at the docs for the `React` version of the OHIF
+> Viewer. If you're looking for the `Meteor` version's documentation (now
+> deprecated), select it's version from the dropdown box in the top left corner
+> of this page.
+
+# Introduction
+
+The [Open Health Imaging Foundation][ohif-org] (OHIF) Viewer is an open source,
+web-based, medical imaging viewer. It can be configured to connect to Image
+Archives that support [DicomWeb][dicom-web], and offers support for mapping to
+proprietary API formats. OHIF maintained extensions add support for viewing,
+annotating, and reporting on DICOM images in 2D (slices) and 3D (volumes).
+
+![OHIF Viewer Screenshot](../assets/img/viewer.png)
+
+<center><i>The <strong>OHIF Viewer</strong>: A general purpose DICOM Viewer (<a href="http://viewer.ohif.org/">Live Demo</a>)</center>
+
+The Open Health Imaging Foundation intends to provide a simple general purpose
+DICOM Viewer which can be easily extended for specific uses. If you find
+yourself unable to extend the viewer for your purposes, please reach out via our
+[GitHub issues][gh-issues]. We are actively seeking feedback on ways to improve
+our integration and extension points.
+
+## Where to next?
+
+Check out these helpful links:
+
+- Ready to dive into some code? Check out our
+  [Getting Started Guide](./development/getting-started.md).
+- We're an active, vibrant community.
+  [Learn how you can be more involved.](./development/contributing.md)
+- Feeling lost? Read our [help page](./help.md).
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[ohif-org]: http://www.ohif.org
+[dicom-web]: https://en.wikipedia.org/wiki/DICOMweb
+[gh-issues]: https://github.com/OHIF/Viewers/issues
+<!-- prettier-ignore-end -->

docs/v2/SUMMARY.md

@@ -0,0 +1,61 @@
+# OHIF Viewers
+
+- [Our Process](our-process.md)
+- Development
+  - [Getting Started](development/getting-started.md)
+  - [Contributing](development/contributing.md)
+  - [Continuous Integration](development/continous-integration.md)
+  - [Testing](development/testing.md)
+- [Configuring](configuring/index.md)
+  - [Data Source](configuring/data-source.md)
+
+---
+
+- [Architecture](architecture/index.md)
+- [Viewer](viewer/index.md)
+  - [Configuration](viewer/configuration.md)
+  - [Themeing](viewer/themeing.md)
+  - [Internationalization](viewer/internationalization.md)
+- [Extensions](extensions/index.md)
+  - [Registering](extensions/index.md#registering-an-extension)
+  - [Lifecycle Hooks](extensions/index.md#lifecycle-hooks)
+    - [preRegistration](extensions/lifecycle/pre-registration.md)
+  - [Modules](extensions/index.md#modules)
+    - [Commands](extensions/modules/commands.md)
+    - [Panel](extensions/modules/panel.md)
+    - [SOP Class Handler](extensions/modules/sop-class-handler.md)
+    - [Toolbar](extensions/modules/toolbar.md)
+    - [Viewport](extensions/modules/viewport.md)
+  - [Contexts](extensions/index.md#contexts)
+  - [ExtensionManager](extensions/index.md#extensionmanager)
+  - [OHIF Maintained](extensions/index.md#maintained-extensions)
+- [Services](services/index.md)
+  - [Default](services/default/index.md)
+  - [UI](services/ui/index.md)
+    - [Dialog Service](services/ui/ui-dialog-service.md)
+    - [Modal Service](services/ui/ui-modal-service.md)
+    - [Notification Service](services/ui/ui-notification-service.md)
+
+---
+
+- [Deployment](deployment/index.md)
+  - [Embedded](deployment/index.md#embedded-viewer)
+  - [Stand-alone](deployment/index.md#stand-alone-viewer)
+  - [Data](deployment/index.md#data)
+- Recipes
+  - Script Include
+    - [Embedding the Viewer](deployment/recipes/embedded-viewer.md)
+  - Stand-Alone
+    - [Build for Production](deployment/recipes/build-for-production.md)
+    - [Static](deployment/recipes/static-assets.md)
+    - [Nginx + Image Archive](deployment/recipes/nginx--image-archive.md)
+    - [User Account Control](deployment/recipes/user-account-control.md)
+    - [Google Cloud Healthcare](connecting-to-image-archives/google-cloud-healthcare.md)
+
+---
+
+- [FAQ](faq/index.md)
+  - [Scope of Project](faq/scope-of-project.md)
+  - [Browser Support](faq/browser-support.md)
+  - [PWA vs Packaged](faq/pwa-vs-packaged.md)
+- [Help](help.md)

docs/v2/architecture/index.md

@@ -0,0 +1,153 @@
+# Architecture
+
+Looking to extend your instance of the OHIF Viewer? Want learn how to reuse _a
+portion_ of the Viewer in your own application? Or maybe you want to get
+involved and draft or suggest a new feature? Regardless, you're in the right
+place!
+
+The OHIF Viewer aims to be decoupled, configurable, and extensible; while this
+allows our code to be used in more ways, it also increases complexity. Below, we
+aim to demistify that complexity by providing insight into how our Viewer is
+architected, and the role each of it's dependent libraries plays.
+
+- [Overview](#overview)
+- [Business Logic](#business-logic)
+- [Component Library](#react-component-library)
+- [Extensions & Configuration](#extensions--configuration)
+- [Common Questions](#common-questions)
+
+## Overview
+
+The [OHIF Medical Image Viewing Platform][viewers-project] is maintained as a
+[`monorepo`][monorepo]. This means that this repository, instead of containing a
+single project, contains many projects. If you explore our project structure,
+you'll see the following:
+
+```bash
+.
+├── extensions
+│   ├── _example            # Skeleton of example extension
+│   ├── cornerstone         # 2D images w/ Cornerstone.js
+│   ├── dicom-html          # Structured Reports as HTML in viewport
+│   ├── dicom-microscopy    # Whole slide microscopy viewing
+│   ├── dicom-pdf           # View DICOM wrapped PDFs in viewport
+│   └── vtk                 # MPR and Volume support w/ VTK.js
+│
+├── platform
+│   ├── core                # Business Logic
+│   ├── i18n                # Internationalization Support
+│   ├── ui                  # React component library
+│   └── viewer              # Connects platform and extension projects
+│
+├── ...                     # misc. shared configuration
+├── lerna.json              # MonoRepo (Lerna) settings
+├── package.json            # Shared devDependencies and commands
+└── README.md
+```
+
+The `platform` directory contains the business logic library, component library,
+and the application library that combines them to create a powerful medical
+imaging viewer.
+
+The `extensions` directory contains many packages that can be registered with
+`@ohif/core`'s `ExtensionManager` to expand an application's supported features
+and functionality.
+
+![Architecture Diagram](../assets/img/architecture-diagram.png)
+
+<center><i>architecture diagram</i></center>
+
+This diagram is a conceptual illustration of how the Viewer is architected.
+
+1. (optional) `extensions` can be registered with `@ohif/core`'s
+   `ExtensionManager`
+2. `@ohif/core` provides bussiness logic and a way for `@ohif/viewer` to access
+   registered extensions
+3. The `@ohif/viewer` composes and provides data to components from our
+   component library (`@ohif/ui`)
+4. The `@ohif/viewer` can be built and served as a stand-alone PWA, or as an
+   embeddable package ([`@ohif/viewer`][viewer-npm])
+
+## Business Logic
+
+The [`@ohif/core`][core-github] project offers pre-packaged solutions for
+features common to Web-based medical imaging viewers. For example:
+
+- Hotkeys
+- DICOM Web requests
+- Hanging Protocols
+- Managing a study's measurements
+- Managing a study's DICOM metadata
+- [A flexible pattern for extensions](../extensions/index.md)
+- And many others
+
+It does this while remaining decoupled from any particular view library or
+rendering logic. While we use it to power our React Viewer, it can be used with
+Vue, React, Vanilla JS, or any number of other frameworks.
+
+## React Component Library
+
+[`@ohif/ui`][ui-github] is a React Component library that contains the reusable
+components that power the OHIF Viewer. It allows us to build, compose, and test
+components in isolation; easing the development process by reducing the need to
+stand-up a local PACS with test case data.
+
+Extension authors can also use these same components when building their
+extension's UI; allowing for a consistent look and feel with the rest of the
+application.
+
+[Check out our component library!](https://react.ohif.org/)
+
+## Extensions & Configuration
+
+While OHIF maintains several high value and commonly requested features in its
+own extensions, there are many instances where one may wish to further extend
+the viewer. Some common use cases include:
+
+- Adding AI/ML tools and insights
+- Custom workflows for guided diagnosis
+- Collecting specific annotations for training data or reports
+- Authentication and granular permissions
+- Teleconsultation workflow, image comments, and tracking
+- Adding surgical templating tools and reports
+- and many others
+
+We expose common integration points via [extensions](../extensions/index.md) to
+make this possible. The viewer and many of our own extensions also offer
+[configuration][configuration]. For a list of extensions maintained by OHIF,
+[check out this helpful table](../extensions/index.md#maintained-extensions).
+
+If you find yourself thinking "I wish the Viewer could do X", and you can't
+accomplish it with an extension today, create a GitHub issue! We're actively
+looking for ways to improve our extensibility ^\_^
+
+[Click here to read more about extensions!](../extensions/index.md)
+
+## Common Questions
+
+> When should I use the packaged source `@ohif/viewer` versus building a PWA
+> from the source?
+
+...
+
+> Can I create my own Viewer using Vue.js or Angular.js?
+
+You can, but you will not be able to leverage as much of the existing code and
+components. `@ohif/core` could still be used for business logic, and to provide
+a model for extensions. `@ohif/ui` would then become a guide for the components
+you would need to recreate.
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[monorepo]: https://github.com/OHIF/Viewers/issues/768
+[viewers-project]: https://github.com/OHIF/Viewers
+[viewer-npm]: https://www.npmjs.com/package/@ohif/viewer
+[pwa]: https://developers.google.com/web/progressive-web-apps/
+[configuration]: ../configuring/index.md
+[extensions]: ../extensions/index.md
+[core-github]: https://github.com/OHIF/viewers/platform/core
+[ui-github]: https://github.com/OHIF/Viewers/tree/master/platform/ui
+<!-- prettier-ignore-end -->

docs/v2/assets/designs/cloud.svg

@@ -0,0 +1,14 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16">
+  <defs id="defs3051">
+    <style type="text/css" id="current-color-scheme">
+      .ColorScheme-Text {
+        color:#4d4d4d;
+      }
+      </style>
+  </defs>
+    <path 
+        style="fill:currentColor;fill-opacity:1;stroke:none" 
+        d="M 7.5 2 A 4.5 4.5 0 0 0 3 6.5 A 4.5 4.5 0 0 0 3.0527344 7.15625 A 3 3 0 0 0 1 10 A 3 3 0 0 0 4 13 L 11.5 13 A 3.5 3.5 0 0 0 15 9.5 A 3.5 3.5 0 0 0 11.970703 6.0351562 A 4.5 4.5 0 0 0 7.5 2 z M 7.5 3 A 3.5 3.5 0 0 1 11 6.5 A 3.5 3.5 0 0 1 10.949219 7.0644531 A 2.5 2.5 0 0 1 11.5 7 A 2.5 2.5 0 0 1 14 9.5 A 2.5 2.5 0 0 1 11.5 12 L 4 12 A 2 2 0 0 1 2 10 A 2 2 0 0 1 4 8 A 2 2 0 0 1 4.3574219 8.0332031 A 3.5 3.5 0 0 1 4 6.5 A 3.5 3.5 0 0 1 7.5 3 z " 
+        id="path4139" 
+        class="ColorScheme-Text"/>
+</svg>

docs/v2/assets/designs/npm-logo-red.svg

@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="utf-8"?>
+<svg version="1.1" id="npm" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
+	 viewBox="0 0 780 250" style="enable-background:new 0 0 780 250;" xml:space="preserve">
+<style type="text/css">
+	.st0{fill:#C12127;}
+</style>
+<path class="st0" d="M240,250h100v-50h100V0H240V250z M340,50h50v100h-50V50z M480,0v200h100V50h50v150h50V50h50v150h50V0H480z
+	 M0,200h100V50h50v150h50V0H0V200z"/>
+</svg>

docs/v2/book.json

@@ -0,0 +1,54 @@
+{
+  "title": "OHIF",
+  "description": "Documentation for the OHIF framework",
+  "gitbook": ">3.0.0",
+  "plugins": [
+    "edit-link",
+    "theme-cornerstone",
+    "-fontsettings",
+    "github",
+    "ga",
+    "sitemap",
+    "anchors",
+    "versions"
+  ],
+  "pluginsConfig": {
+    "edit-link": {
+      "base": "https://github.com/OHIF/Viewers/edit/master/docs",
+      "label": "Edit This Page"
+    },
+    "github": {
+      "url": "https://github.com/OHIF/Viewers"
+    },
+    "ga": {
+      "token": "UA-110573590-2"
+    },
+    "sitemap": {
+      "hostname": "https://docs.ohif.org"
+    },
+    "versions": {
+      "gitbookConfigURL": "https://raw.githubusercontent.com/OHIF/Viewers/master/docs/book.json",
+      "options": [
+        {
+          "value": "https://docs.ohif.org/history/v1/",
+          "text": "Version 1.0.0 (Meteor)"
+        },
+        {
+          "value": "https://docs.ohif.org/history/v2/",
+          "text": "Version 2.0.0",
+          "selected": true
+        },
+        {
+          "value": "https://docs.ohif.org/",
+          "text": "Version 3.0.0"
+        }
+      ]
+    }
+  },
+  "links": {
+    "sharing": {
+      "facebook": false,
+      "twitter": false
+    }
+  }
+}

docs/v2/configuring/data-source.md

@@ -0,0 +1,170 @@
+# Data Source
+
+After following the steps outlined in
+[Getting Started](./../development/getting-started.md), you'll notice that the
+OHIF Viewer has data for several studies and their images. You didn't add this
+data, so where is it coming from?
+
+By default, the viewer is configured to connect to a remote server hosted by the
+nice folks over at [dcmjs.org][dcmjs-org]. While convenient for getting started,
+the time may come when you want to develop using your own data either locally or
+remotely.
+
+## Set up a local DICOM server
+
+> ATTENTION! Already have a remote or local server? Skip to the
+> [configuration section](#configuration-learn-more) below.
+
+While the OHIF Viewer can work with any data source, the easiest to configure
+are the ones that follow the [DICOMWeb][dicom-web] spec.
+
+1. Choose and install an Image Archive
+2. Upload data to your archive (e.g. with DCMTK's [storescu][storescu] or your
+   archive's web interface)
+3. Keep the server running
+
+For our purposes, we will be using `Orthanc`, but you can see a list of
+[other Open Source options](#open-source-dicom-image-archives) below.
+
+### Requirements
+
+- Docker
+  - [Docker for Mac](https://docs.docker.com/docker-for-mac/)
+  - [Docker for Windows (recommended)](https://docs.docker.com/docker-for-windows/)
+  - [Docker Toolbox for Windows](https://docs.docker.com/toolbox/toolbox_install_windows/)
+
+_Not sure if you have `docker` installed already? Try running `docker --version`
+in command prompt or terminal_
+
+> If you are using `Docker Toolbox` you need to change the _PROXY_DOMAIN_
+> parameter in _platform/viewer/package.json_ to http://192.168.99.100:8042 or
+> the ip docker-machine ip throws. This is the value [`WebPack`][webpack-proxy]
+> uses to proxy requests
+
+### Running Orthanc
+
+_Start Orthanc:_
+
+```bash
+# Runs orthanc so long as window remains open
+yarn run orthanc:up
+```
+
+_Upload your first Study:_
+
+1. Navigate to
+   [Orthanc's web interface](http://localhost:8042/app/explorer.html) at
+   `http://localhost:8042/app/explorer.html` in a web browser.
+2. In the top right corner, click "Upload"
+3. Click "Select files to upload..." and select one or more DICOM files
+4. Click "Start the upload"
+
+#### Orthanc: Learn More
+
+You can see the `docker-compose.yml` file this command runs at
+[`<project-root>/.docker/Nginx-Orthanc/`][orthanc-docker-compose], and more on
+Orthanc for Docker in [Orthanc's documentation][orthanc-docker].
+
+### Connecting to Orthanc
+
+Now that we have a local Orthanc instance up and running, we need to configure
+our web application to connect to it. Open a new terminal window, navigate to
+this repository's root directory, and run:
+
+```bash
+# If you haven't already, enable yarn workspaces
+yarn config set workspaces-experimental true
+
+# Restore dependencies
+yarn install
+
+# Run our dev command, but with the local orthanc config
+yarn run dev:orthanc
+```
+
+#### Configuration: Learn More
+
+> For more configuration fun, check out the
+> [Essentials Configuration](./index.md) guide.
+
+Let's take a look at what's going on under the hood here. `yarn run dev:orthanc`
+is running the `dev:orthanc` script in our project's `package.json`. That script
+is:
+
+```js
+cross-env NODE_ENV=development PROXY_TARGET=/dicom-web PROXY_DOMAIN=http://localhost:8042 APP_CONFIG=config/docker_nginx-orthanc.js webpack-dev-server --config .webpack/webpack.pwa.js -w
+```
+
+- `cross-env` sets three environment variables
+  - PROXY_TARGET: `/dicom-web`
+  - PROXY_DOMAIN: `http://localhost:8042`
+  - APP_CONFIG: `config/docker_nginx-orthanc.js`
+- `webpack-dev-server` runs using the `.webpack/webpack.pwa.js` configuration
+  file. It will watch for changes and update as we develop.
+
+`PROXY_TARGET` and `PROXY_DOMAIN` tell our development server to proxy requests
+to `Orthanc`. This allows us to bypass CORS issues that normally occur when
+requesting resources that live at a different domain.
+
+The `APP_CONFIG` value tells our app which file to load on to `window.config`.
+By default, our app uses the file at
+`<project-root>/platform/viewer/public/config/default.js`. Here is what that
+configuration looks like:
+
+```js
+window.config = {
+  routerBasename: '/',
+  servers: {
+    dicomWeb: [
+      {
+        name: 'Orthanc',
+        wadoUriRoot: 'http://localhost:8899/wado',
+        qidoRoot: 'http://localhost:8899/dicom-web',
+        wadoRoot: 'http://localhost:8899/dicom-web',
+        qidoSupportsIncludeField: false,
+        imageRendering: 'wadors',
+        thumbnailRendering: 'wadors',
+      },
+    ],
+  },
+};
+```
+
+To learn more about how you can configure the OHIF Viewer, check out our
+[Configuration Guide](./index.md).
+
+## Open Source DICOM Image Archives
+
+Our example uses `Orthanc`, but there are a lot of options available to you.
+Here are some of the more popular ones:
+
+| Archive                                       | Installation                       |
+| --------------------------------------------- | ---------------------------------- |
+| [DCM4CHEE Archive 5.x][dcm4chee]              | [W/ Docker][dcm4chee-docker]       |
+| [Orthanc][orthanc]                            | [W/ Docker][orthanc-docker]        |
+| [DICOMcloud][dicomcloud] (**DICOM Web only**) | [Installation][dicomcloud-install] |
+| [OsiriX][osirix] (**Mac OSX only**)           | Desktop Client                     |
+| [Horos][horos] (**Mac OSX only**)             | Desktop Client                     |
+
+_Feel free to make a Pull Request if you want to add to this list._
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[dcmjs-org]: https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado
+[dicom-web]: https://en.wikipedia.org/wiki/DICOMweb
+[storescu]: http://support.dcmtk.org/docs/storescu.html
+[webpack-proxy]: https://webpack.js.org/configuration/dev-server/#devserverproxy
+[orthanc-docker-compose]: https://github.com/OHIF/Viewers/tree/master/.docker/Nginx-Orthanc
+<!-- Archives -->
+[dcm4chee]: https://github.com/dcm4che/dcm4chee-arc-light
+[dcm4chee-docker]: https://github.com/dcm4che/dcm4chee-arc-light/wiki/Running-on-Docker
+[orthanc]: https://www.orthanc-server.com/
+[orthanc-docker]: http://book.orthanc-server.com/users/docker.html
+[dicomcloud]: https://github.com/DICOMcloud/DICOMcloud
+[dicomcloud-install]: https://github.com/DICOMcloud/DICOMcloud#running-the-code
+[osirix]: http://www.osirix-viewer.com/
+[horos]: https://www.horosproject.org/
+<!-- prettier-ignore-end -->

docs/v2/configuring/index.md

@@ -0,0 +1,126 @@
+# Configuration
+
+> This step assumes you have an imaging archive. If you need assistance setting
+> one up, check out the [`Data Source` Guide](./data-source.md) or a deployment
+> recipe that contains an open Image Archive
+
+- [Overview](#overview)
+  - [Configuration Files](#configuration-files)
+  - [Environment Variables](#environment-variables)
+- [How do I configure my project?](#how-do-i-configure-my-project)
+
+## Overview
+
+### Configuration Files
+
+The configuration for our viewer is in the `<root>platform/viewer/public/config`
+directory. Our build process knows which configuration file to use based on the
+`APP_CONFIG` environment variable. By default, its value is
+[`config/default.js`][default-config]. The majority of the viewer's features,
+and registered extension's features, are configured using this file.
+
+**Embedded Use Note:**
+
+Alternatively, when using the `umd` bundle for embedded use cases, these same
+values are what you'll pass to `installViewer` method:
+
+`OHIFStandaloneViewer.installViewer(window.config)`
+
+### Environment Variables
+
+We use environment variables at build and dev time to change the Viewer's
+behavior. We can update the `HTML_TEMPLATE` to easily change which extensions
+are registered, and specify a different `APP_CONFIG` to connect to an
+alternative data source (or even specify different default hotkeys).
+
+| Environment Variable | Description                                                                                        | Default             |
+| -------------------- | -------------------------------------------------------------------------------------------------- | ------------------- |
+| `HTML_TEMPLATE`      | Which [HTML template][html-templates] to use as our web app's entry point. Specific to PWA builds. | `index.html`        |
+| `PUBLIC_URL`         | The route relative to the host that the app will be served from. Specific to PWA builds.           | `/`                 |
+| `APP_CONFIG`         | Which [configuration file][config-file] to copy to output as `app-config.js`                       | `config/default.js` |
+| `PROXY_TARGET`       | When developing, proxy requests that match this pattern to `PROXY_DOMAIN`                          | `undefined`         |
+| `PROXY_DOMAIN`       | When developing, proxy requests from `PROXY_TARGET` to `PROXY_DOMAIN`                              | `undefined`         |
+
+## How do I configure my project?
+
+The simplest way is to update the existing default config:
+
+_/platform/viewer/public/config/default.js_
+
+```js
+window.config = {
+  routerBasename: '/',
+  servers: {
+    dicomWeb: [
+      {
+        name: 'DCM4CHEE',
+        wadoUriRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado',
+        qidoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
+        wadoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
+        qidoSupportsIncludeField: true,
+        imageRendering: 'wadors',
+        thumbnailRendering: 'wadors',
+      },
+    ],
+  },
+};
+```
+
+The configuration can also be written as a JS Function in case you need to inject dependencies like external services:
+
+```js
+window.config = ({ servicesManager } = {}) => {
+  const { UIDialogService } = servicesManager.services;
+  return {
+    cornerstoneExtensionConfig: {
+      tools: {
+        ArrowAnnotate: {
+          configuration: {
+            getTextCallback: (callback, eventDetails) => UIDialogService.create({...
+          }
+        }
+      },
+    },
+    routerBasename: '/',
+    servers: {
+      dicomWeb: [
+        {
+          name: 'DCM4CHEE',
+          wadoUriRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado',
+          qidoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
+          wadoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
+          qidoSupportsIncludeField: true,
+          imageRendering: 'wadors',
+          thumbnailRendering: 'wadors',
+        },
+      ],
+    },
+  };
+};
+```
+
+You can also create a new config file and specify its path relative to the build
+output's root by setting the `APP_CONFIG` environment variable. You can set the
+value of this environment variable a few different ways:
+
+- ~[Add a temporary environment variable in your shell](https://facebook.github.io/create-react-app/docs/adding-custom-environment-variables#adding-temporary-environment-variables-in-your-shell)~
+  - Previous `react-scripts` functionality that we need to duplicate with
+    `dotenv-webpack`
+- ~[Add environment specific variables in `.env` file(s)](https://facebook.github.io/create-react-app/docs/adding-custom-environment-variables#adding-development-environment-variables-in-env)~
+  - Previous `react-scripts` functionality that we need to duplicate with
+    `dotenv-webpack`
+- Using the `cross-env` package in an npm script:
+  - `"build": "cross-env APP_CONFIG=config/my-config.js react-scripts build"`
+
+After updating the configuration, `yarn run build` to generate updated build
+output.
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[default-config]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/public/config/default.js
+[html-templates]: https://github.com/OHIF/Viewers/tree/master/platform/viewer/public/html-templates
+[config-files]: https://github.com/OHIF/Viewers/tree/master/platform/viewer/public/config
+<!-- prettier-ignore-end -->

docs/v2/connecting-to-image-archives/google-cloud-healthcare.md

@@ -0,0 +1,71 @@
+# Google Cloud Healthcare
+
+> The [Google Cloud Healthcare API](https://cloud.google.com/healthcare/) is a
+> powerful option for storing medical imaging data in the cloud.
+
+An alternative to deploying your own PACS is to use a software-as-a-service
+provider such as Google Cloud. The Cloud Healthcare API promises to be a
+scalable, secure, cost effective image storage solution for those willing to
+store their data in the cloud. It offers an
+[almost-entirely complete DICOMWeb API](https://cloud.google.com/healthcare/docs/dicom)
+which requires tokens generated via the
+[OAuth 2.0 Sign In flow](https://developers.google.com/identity/sign-in/web/sign-in).
+Images can even be transcoded on the fly if this is desired.
+
+## Setup a Google Cloud Healthcare Project
+
+- Create a Google Cloud account
+- Create a project in Google Cloud
+- Enable the [Cloud Healthcare API](https://cloud.google.com/healthcare/) for
+  your project.
+  - (Optional): Create a Dataset and Data Store for storing your DICOM data
+- Enable the
+  [Cloud Resource Manager API](https://cloud.google.com/resource-manager/) for
+  your project.
+  - _Note:_ If you are having trouble finding the APIs, use the search box at
+    the top of the Cloud console.
+- Go to APIs & Services > Credentials to create an OAuth Consent screen and fill
+  in your application details.
+  - Under Scopes for Google APIs, click "manually paste scopes".
+  - Add the following scopes:
+    - `https://www.googleapis.com/auth/cloudplatformprojects.readonly`
+    - `https://www.googleapis.com/auth/cloud-healthcare`
+- Go to APIs & Services > Credentials to create a new set of credentials:
+
+  - Choose the "Web Application" type
+  - Set up an
+    [OAuth 2.0 Client ID](https://support.google.com/cloud/answer/6158849?hl=en)
+  - Add your domain (e.g. `http://localhost:3000`) to Authorized JavaScript
+    origins.
+  - Add your domain, plus `callback` (e.g. `http://localhost:3000/callback`) to
+    Authorized Redirect URIs.
+  - Save your Client ID for later.
+
+- (Optional): Enable Public Datasets that are being hosted by Google:
+  https://cloud.google.com/healthcare/docs/resources/public-datasets/
+
+## Run the viewer with your OAuth Client ID
+
+1. Open the `config/google.js` file and change `YOURCLIENTID` to your Client ID
+   value.
+1. Run the OHIF Viewer using the config/google.js configuration file
+
+```bash
+cd OHIFViewer
+yarn install
+APP_CONFIG=config/google.js yarn run dev
+```
+
+## Running via Docker
+
+The OHIF Viewer Docker container can be connected to Google Cloud Healthcare by
+providing a Client ID at runtime. This is a very simple method to get up and
+running.
+
+1. Install Docker (https://www.docker.com/)
+1. Run the Docker container, providing a Client ID as an environment variable.
+   Client IDs look like `xyz.apps.googleusercontent.com`.
+
+```bash
+docker run --env CLIENT_ID=$CLIENT_ID --publish 5000:80 ohif/viewer:latest
+```

docs/v2/deployment/_embedded-viewer-diagram.md

@@ -0,0 +1,4 @@
+<div style="text-align: center;">
+  <img src="/assets/img/embedded-viewer-diagram.png" alt="Embedded Viewer Diagram" style="margin: 0 auto;" />
+  <div><i>embedded viewer diagram</i></div>
+</div>

docs/v2/deployment/_nginx-image-archive-diagram.md

@@ -0,0 +1,4 @@
+<div style="text-align: center;">
+  <img src="/assets/img/nginx-image-archive.png" alt="request flow example" style="margin: 0 auto;" />
+  <div><i>simplified request flow diagram</i></div>
+</div>

docs/v2/deployment/_user-account-control-flow-diagram.md

@@ -0,0 +1,4 @@
+<div style="text-align: center;">
+  <img src="/assets/img/user-access-control-request-flow.png" alt="request flow example" style="margin: 0 auto;" />
+  <div><i>simplified request flow diagram</i></div>
+</div>

docs/v2/deployment/index.md

@@ -0,0 +1,305 @@
+# Deployment
+
+The OHIF Viewer can be embedded in other web applications via it's [packaged
+script source][viewer-npm], or served up as a stand-alone PWA ([progressive web
+application][pwa-url]) by building and hosting a collection of static assets. In
+either case, you will need to configure your instance of the Viewer so that it
+can connect to your data source (the database or PACS that provides the data
+your Viewer will display).
+
+## Overview
+
+Our goal is to make deployment as simple and painless as possible; however,
+there is an inherent amount of complexity in configuring and deploying web
+applications. If you find yourself a little lost, please don't hesitate to
+[reach out for help](/help.md)
+
+## Deployment Scenarios
+
+### Embedded Viewer
+
+The quickest and easiest way to get the OHIF Viewer up and running is to embed
+it into an existing web application. It allows us to forego a "build step", and
+add a powerful medical imaging viewer to an existing web page using only a few
+include tags.
+
+- Read more about it here: [Embedded Viewer](./recipes/embedded-viewer.md)
+- And check out our [live demo on CodeSandbox][code-sandbox]
+
+{% include "./_embedded-viewer-diagram.md" %}
+
+### Stand-alone Viewer
+
+Deploying the OHIF Viewer as a stand-alone web application provides many
+benefits, but comes at the cost of time and complexity. Some benefits include:
+
+_Today:_
+
+- Leverage [extensions](/extensions/index.md) to drop-in powerful new features
+- Add routes and customize the viewer's workflow
+- Finer control over styling and whitelabeling
+
+_In the future:_
+
+- The ability to package the viewer for [App Store distribution][app-store]
+- Leverage `service-workers` for offline support and speed benefits from caching
+
+#### Hosted Static Assets
+
+At the end of the day, a production OHIF Viewer instance is a collection of
+HTML, CSS, JS, Font Files, and Images. We "build" those files from our
+`source code` with configuration specific to our project. We then make those
+files publicly accessible by hosting them on a Web Server.
+
+If you have not deployed a web application before, this may be a good time to
+[reach out for help](/help.md), as these steps assume prior web development and
+deployment experience.
+
+##### Part 1 - Build Production Assets
+
+"Building", or creating, the files you will need is the same regardless of the
+web host you choose. You can find detailed instructions on how to configure and
+build the OHIF Viewer in our
+["Build for Production" guide](./recipes/build-for-production.md).
+
+##### Part 2 - Host Your App
+
+There are a lot of [benefits to hosting static assets][host-static-assets] over
+dynamic content. You can find instructions on how to host your build's output
+via one of these guides:
+
+_Drag-n-drop_
+
+- [Netlify: Drop](/deployment/recipes/static-assets.md#netlify-drop)
+
+_Easy_
+
+- [Surge.sh](/deployment/recipes/static-assets.md#surgesh)
+- [GitHub Pages](/deployment/recipes/static-assets.md#github-pages)
+
+_Advanced_
+
+- [AWS S3 + Cloudfront](/deployment/recipes/static-assets.md#aws-s3--cloudfront)
+- [GCP + Cloudflare](/deployment/recipes/static-assets.md#gcp--cloudflare)
+- [Azure](/deployment/recipes/static-assets.md#azure)
+
+## Data
+
+The OHIF Viewer is able to connect to any data source that implements the [DICOM
+Web Standard][dicom-web-standard]. [DICOM Web][dicom-web] refers to RESTful
+DICOM Services -- a recently standardized set of guidelines for exchanging
+medical images and imaging metadata over the internet. Not all archives fully
+support it yet, but it is gaining wider adoption.
+
+### Configure Connection
+
+If you have an existing archive and intend to host the OHIF Viewer at the same
+domain name as your archive, then connecting the two is as simple as following
+the steps layed out in our
+[Configuration Essentials Guide](./../configuring/index.md).
+
+#### What if I don't have an imaging archive?
+
+We provide some guidance on configuring a local image archive in our
+[Data Source Essentials](./../configuring/data-source.md) guide. Hosting an
+archive remotely is a little trickier. You can check out some of our
+[advanced recipes](#recipes) for modeled setups that may work for you.
+
+#### What if I intend to host the OHIF Viewer at a different domain?
+
+There are two important steps to making sure this setup works:
+
+1. Your Image Archive needs to be exposed, in some way, to the open web. This
+   can be directly, or through a `reverse proxy`, but the Viewer needs _some
+   way_ to request it's data.
+2. \* Your Image Archive needs to have appropriate CORS (Cross-Origin Resource
+   Sharing) Headers
+
+> \* Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional
+> HTTP headers to tell a browser to let a web application running at one origin
+> (domain) have permission to access selected resources from a server at a
+> different origin. - [MDN Web Docs: Web - Http - CORS][cors]
+
+Most image archives do not provide either of these features "out of the box".
+It's common to use IIS, Nginx, or Apache to route incoming requests and append
+appropriate headers. You can find an example of this setup in our
+[Nginx + Image Archive Deployment Recipe](./recipes/nginx--image-archive.md).
+
+#### What if my archive doesn't support DicomWeb?
+
+It's possible to supply all Study data via JSON format, in the event you do not have a DicomWeb endpoint.
+You can host all of the relevant files on any web accessible server (Amazon S3, Azure Blob Storage, Local file server etc.)
+
+This JSON is supplied via the '?url=' query parameter.
+It should reference an endpoint that returns **application/json** formatted text.
+
+If you do not have an API, you can simply return a text file containing the JSON from any web server.
+
+
+You tell the OHIF viewer to use JSON by appending the `'?url='` query to the `/Viewer` route:
+
+eg. `https://my-test-ohif-server/viewer?url=https://my-json-server/study-uid.json`
+
+The returned JSON object must contain a single root object with a 'studies' array.
+
+
+*Sample JSON format:*
+```JSON
+{
+    "studies": [
+      {
+        "StudyInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.78",
+        "StudyDescription": "BRAIN SELLA",
+        "StudyDate": "20010108",
+        "StudyTime": "120022",
+        "PatientName": "MISTER^MR",
+        "PatientId": "832040",
+        "series": [
+          {
+            "SeriesDescription": "SAG T-1",
+            "SeriesInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.121",
+            "SeriesNumber": 2,
+            "SeriesDate": "20010108",
+            "SeriesTime": "120318",
+            "Modality": "MR",
+            "instances": [
+              {
+                "metadata": {
+                    "Columns": 512,
+                    "Rows": 512,
+                    "InstanceNumber": 3,
+                    "AcquisitionNumber": 0,
+                    "PhotometricInterpretation": "MONOCHROME2",
+                    "BitsAllocated": 16,
+                    "BitsStored": 16,
+                    "PixelRepresentation": 1,
+                    "SamplesPerPixel": 1,
+                    "PixelSpacing": [0.390625, 0.390625],
+                    "HighBit": 15,
+                    "ImageOrientationPatient": [0,1,0,0,0,-1],
+                    "ImagePositionPatient": [11.600000,-92.500000, 98.099998],
+                    "FrameOfReferenceUID": "1.2.840.113619.2.5.1762583153.223134.978956938.470",
+                    "ImageType": ["ORIGINAL","PRIMARY","OTHER"],
+                    "Modality": "MR",
+                    "SOPInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.124",
+                    "SeriesInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.121",
+                    "StudyInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.78"
+                },
+                "url": "dicomweb://s3.amazonaws.com/lury/MRStudy/1.2.840.113619.2.5.1762583153.215519.978957063.124.dcm"
+             }
+           ]
+         }
+       ]
+     }
+   ]
+}
+```
+More info on this JSON format can be found here [Issue #1500](https://github.com/OHIF/Viewers/issues/1500)
+
+
+**Implementation Notes:**
+
+1. When hosting the viewer, you will also need to host a /viewer route on the server - or the browser may not be able to find the route.
+2. For each instance url (dicom object) in the returned JSON, you must prefix the `url` with `dicomweb:` in order for the cornerstone image loader to retrieve it correctly.
+ eg. `https://image-server/my-image.dcm` ---> `dicomweb:https://image-server/my-image.dcm`
+3. The JSON format above is compatible with >= v3.7.8 of the application. Older versions of the viewer used a different JSON format. As of 20/04/20 the public [https://viewer.ohif.org/] is a pre 3.0 version that does not support this format yet.
+4. The JSON format is case-sensitive. Please ensure you have matched casing with the naturalised Dicom format referenced in [Issue #1500](https://github.com/OHIF/Viewers/issues/1500).
+
+*CORS Issues (Cross-Origin Resource Sharing)*
+
+If you host a JSON API or Images on a different domain from the the app itself, you will likely have CORS issues. This will also happen when testing from Localhost and reaching out to remote servers.
+Even if the domain is the same, different ports, subdomains or protocols (https vs http) will also cause CORS errors.
+You will to need add a configuration on each server hosting these assets to allow your App server origin.
+
+For example:
+
+Lets assume your application is hosted on `https://my-ohif-server.com`.
+
+Your JSON API is hosted on `https://my-json-api.aws.com`
+
+And your images are stored on Amazon S3 at `https://my-s3-bucket.aws.com`
+
+When you first start your application, browsing to `https://my-ohif-server.com/viewer?url=https://my-json-api.aws.com/api/my-json-study-info.json`, you will likely get a CORS error in the browser console as it tries to connect to `https://my-json-api.aws.com`.
+
+Adding a setting on the JSON server to allow the CORS origin = `https://my-ohif-server.com` should solve this.
+
+Next, you will likely get a similar CORS error, as the browser tries to go to `https://my-s3-bucket.aws.com`.
+You will need to go to the S3 bucket configuration, and add a CORS setting to allow origin = `https://my-ohif-server.com`.
+
+Essentially, whenever the application connects to a remote resource, you will need to add the applications url to the allowed CORS Origins on that resource. Adding an origin similar to https://localhost:3000 will also allow for local testing.
+
+
+### Securing Your Data
+
+> Feeling lost? Securing your data is important, and it can be hard to tell if
+> you've gotten it right. Don't hesitate to work with professional auditors, or
+> [enlist help from experts](./../help.md).
+
+The OHIF Viewer can be configured to work with authorization servers that
+support one or more of the OpenID-Connect authorization flows. The Viewer finds
+it's OpenID-Connect settings on the `oidc` configuration key. You can set these
+values following the instructions laid out in the
+[Configuration Essentials Guide](./../configuring/index.md).
+
+_Example OpenID-Connect Settings:_
+
+```js
+window.config = {
+  ...
+  oidc: [
+    {
+      // ~ REQUIRED
+      // Authorization Server URL
+      authority: 'http://127.0.0.1/auth/realms/ohif',
+      client_id: 'ohif-viewer',
+      redirect_uri: 'http://127.0.0.1/callback', // `OHIFStandaloneViewer.js`
+      response_type: 'code', // "Authorization Code Flow"
+      scope: 'openid', // email profile openid
+      // ~ OPTIONAL
+      post_logout_redirect_uri: '/logout-redirect.html',
+    },
+  ],
+}
+```
+
+You can find an example of this setup in our
+[User Account Control Deployment Recipe](./recipes/user-account-control.md).
+
+#### Choosing a Flow for the Viewer
+
+In general, we recommend using the "Authorization Code Flow" ( [see
+`response_type=code` here][code-flows]); however, the "Implicit Flow" ( [see
+`response_type=token` here][code-flows]) can work if additonal precautions are
+taken. If the flow you've chosen produces a JWT Token, it's validity can be used
+to secure access to your Image Archive as well.
+
+### Recipes
+
+We've included a few recipes for common deployment scenarios. There are many,
+many possible configurations, so please don't feel limited to these setups.
+Please feel free to suggest or contribute your own recipes.
+
+- Script Include
+  - [Embedding the Viewer](./recipes/embedded-viewer.md)
+- Stand-Alone
+  - [Build for Production](./recipes/build-for-production.md)
+  - [Static](./recipes/static-assets.md)
+  - [Nginx + Image Archive](./recipes/nginx--image-archive.md)
+  - [User Account Control](./recipes/user-account-control.md)
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[viewer-npm]: https://www.npmjs.com/package/@ohif/viewer
+[pwa-url]: https://developers.google.com/web/progressive-web-apps/
+[static-assets-url]: https://www.maxcdn.com/one/visual-glossary/static-content/
+[app-store]: https://medium.freecodecamp.org/i-built-a-pwa-and-published-it-in-3-app-stores-heres-what-i-learned-7cb3f56daf9b
+[dicom-web-standard]: https://www.dicomstandard.org/dicomweb/
+[dicom-web]: https://en.wikipedia.org/wiki/DICOMweb
+[host-static-assets]: https://www.netlify.com/blog/2016/05/18/9-reasons-your-site-should-be-static/
+[cors]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
+[code-flows]: https://medium.com/@darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660
+[code-sandbox]: https://codesandbox.io/s/viewer-script-tag-tprch
+<!-- prettier-ignore-end -->

docs/v2/deployment/recipes/build-for-production.md

@@ -0,0 +1,135 @@
+# Build for Production
+
+> If you've already followed the
+> ["Getting Started" Guide](/development/getting-started.md), you can skip ahead
+> to [Configuration](#configuration)
+
+## Overview
+
+### Build Machine Requirements
+
+- [Node.js & NPM](https://nodejs.org/en/download/)
+- [Yarn](https://yarnpkg.com/lang/en/docs/install/)
+- [Git](https://www.atlassian.com/git/tutorials/install-git)
+
+### Getting the Code
+
+_With Git:_
+
+```bash
+# Clone the remote repository to your local machine
+git clone https://github.com/OHIF/Viewers.git
+```
+
+More on: _[`git clone`](https://git-scm.com/docs/git-clone),
+[`git checkout`](https://git-scm.com/docs/git-checkout)_
+
+_From .zip:_
+
+[OHIF/Viewers: react.zip](https://github.com/OHIF/Viewers/archive/master.zip)
+
+### Restore Dependencies & Build
+
+Open your terminal, and navigate to the directory containing the source files.
+Next run these commands:
+
+```js
+// If you haven't already, enable yarn workspaces
+yarn config set workspaces-experimental true
+
+// Restore dependencies
+yarn install
+
+// Build source code for production
+yarn run build
+```
+
+If everything worked as expected, you should have a new `dist/` directory in the
+project's folder. It should roughly resemble the following:
+
+```bash
+<root>platform/viewer/dist/
+├── app-config.js
+├── app.bundle.js
+├── app.css
+├── index.html
+├── manifest.json
+├── service-worker.js
+└── ...
+```
+
+By default, the build output will connect to OHIF's publicly accessible PACS. If
+this is your first time setting up the OHIF Viewer, it is recommended that you
+test with these default settings. After testing, you can find instructions on
+how to configure the project for your own imaging archive below.
+
+### Configuration
+
+The configuration for our viewer is in the `<root>platform/viewer/public/config`
+directory. Our build process knows which configuration file to use based on the
+`APP_CONFIG` environment variable. By default, its value is
+[`config/default.js`][default-config]. The majority of the viewer's features,
+and registered extension's features, are configured using this file.
+
+The easiest way to apply your own configuration is to modify the `default.js`
+file. For more advanced cofiguration options, check out our
+[configuration essentials guide](/configuring/index.md).
+
+## Next Steps
+
+### Deploying Build Output
+
+_Drag-n-drop_
+
+- [Netlify: Drop](/deployment/recipes/static-assets.md#netlify-drop)
+
+_Easy_
+
+- [Surge.sh](/deployment/recipes/static-assets.md#surgesh)
+- [GitHub Pages](/deployment/recipes/static-assets.md#github-pages)
+
+_Advanced_
+
+- [AWS S3 + Cloudfront](/deployment/recipes/static-assets.md#aws-s3--cloudfront)
+- [GCP + Cloudflare](/deployment/recipes/static-assets.md#gcp--cloudflare)
+- [Azure](/deployment/recipes/static-assets.md#azure)
+
+### Testing Build Output Locally
+
+A quick way to test your build output locally is to spin up a small webserver.
+You can do this by running the following commands in the `dist/` output
+directory:
+
+```js
+// Install http-server as a globally available package
+yarn global add http-server
+
+// Serve the files in our current directory
+// Accessible at: `http://localhost:8080`
+http-server
+```
+
+### Automating Builds and Deployments
+
+If you found setting up your environmnent and running all of these steps to be a
+bit tedious, then you are in good company. Thankfully, there are a large number
+of tools available to assist with automating tasks like building and deploying
+web application. For a starting point, check out this repository's own use of:
+
+- [CircleCI][circleci]: [config.yaml][circleci-config]
+- [Netlify][netlify]: [netlify.toml][netlify.toml] |
+  [build-deploy-preview.sh][build-deploy-preview.sh]
+
+## Troubleshooting
+
+> Issues and resolutions for common GitHub issues will be summarized here
+
+...
+
+<!-- prettier-ignore-start -->
+[circleci]: https://circleci.com/gh/OHIF/Viewers
+[circleci-config]: https://github.com/OHIF/Viewers/blob/master/.circleci/config.yml
+[netlify]: https://app.netlify.com/sites/ohif/deploys
+[netlify.toml]: https://github.com/OHIF/Viewers/blob/master/netlify.toml
+[build-deploy-preview.sh]: https://github.com/OHIF/Viewers/blob/master/.netlify/build-deploy-preview.sh
+<!-- prettier-ignore-end -->

docs/v2/deployment/recipes/embedded-viewer.md

@@ -0,0 +1,171 @@
+# Embedded Viewer
+
+The quickest and easiest way to get the OHIF Viewer up and running is to embed
+it into an existing web application. It allows us to forego a "build step", and
+add a powerful medical imaging viewer to an existing web page using only a few
+include tags. Here's how it works:
+
+{% include "./../_embedded-viewer-diagram.md" %}
+
+1. Create a new web page or template that includes the following external
+   dependencies:
+
+<ul>
+  <li>
+    <a href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700&display=swap">
+      <code>Google Font: Roboto</code>
+    </a>
+  </li>
+  <li>
+    <a href="https://unpkg.com/@ohif/viewer">
+      <code>@ohif/viewer@latest</code>
+    </a>
+  </li>
+</ul>
+
+<ol start="2">
+  <li>Create a JS Object or Function to hold the OHIF Viewer's configuration. Here are some
+   example values that would allow the viewer to hit our public PACS:</li>
+</ol>
+
+```js
+// Set before importing `ohif-viewer` (JS Object)
+window.config = {
+  // default: '/'
+  routerBasename: '/',
+  servers: {
+    dicomWeb: [
+      {
+        name: 'DCM4CHEE',
+        wadoUriRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado',
+        qidoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
+        wadoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
+        qidoSupportsIncludeField: true,
+        imageRendering: 'wadors',
+        thumbnailRendering: 'wadors',
+      },
+    ],
+  },
+};
+```
+
+To learn more about how you can configure the OHIF Viewer, check out our
+[Configuration Guide](../../configuring/index.md).
+
+<ol start="3"><li>
+  Render the viewer in the web page's target <code>div</code>
+</li></ol>
+
+```js
+// Made available by the `@ohif/viewer` script included in step 1
+var containerId = 'id-of-div-to-render-component-to';
+var componentRenderedOrUpdatedCallback = function() {
+  console.log('OHIF Viewer rendered/updated');
+};
+window.OHIFViewer.installViewer(
+  window.config,
+  containerId,
+  componentRenderedOrUpdatedCallback
+);
+```
+
+You can see a live example of this recipe in [this CodeSandbox][code-sandbox].
+
+## Add Extensions
+
+The UMD build of the OHIF Viewer is a "light weight" build that only contains
+the core extensions required for basic 2D image viewing. It's possible to add
+other extensions at runtime.
+
+This only requires us to include a single script tag, and add it using the
+`extensions` key to our config. In this practical example, we register our
+popular whole slide microscopy extension:
+
+```html
+<script
+  src="https://unpkg.com/@ohif/extension-dicom-microscopy@0.50.5/dist/index.umd.js"
+  crossorigin
+></script>
+
+<!-- --->
+<script>
+  window.config = {
+    // ...
+    extensions: [OHIFExtDicomMicroscopy],
+  };
+</script>
+```
+
+You can see an example of a slide microscopy study in the viewer [with the
+extension enabled here][whole-slide-ext-demo] ([source code][ext-code-sandbox])
+and [without it here][whole-slide-base-demo] ([source code][code-sandbox]).
+
+You can read more about extensions and how to create your own in our
+[extensions guide](/extensions/index.md).
+
+#### FAQ
+
+> I'm having trouble getting this to work. Where can I go for help?
+
+First, check out this fully functional [CodeSandbox][code-sandbox] example. If
+you're still having trouble, feel free to search or GitHub issues. Can't find
+anything related your problem? Create a new one.
+
+> My application's styles are impacting the OHIF Viewer's look and feel. What
+> can I do?
+
+When you include stylesheets and scripts, they are added globally. This has the
+potential of causing conflicts with other scripts and styles on the page. To
+prevent this, `embed` the viewer in a new/empty web page. Have that working?
+Good. Now `embed` that new page using an
+[`<iframe>` element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe).
+
+This should produce the expected result while also protecting your page from any
+globally defined styles/scripts.
+
+> We're trying to embed the OHIF Viewer into an existing React App, but seeing
+> react-dom and react conflicts. What can we do?
+
+If you are installing OHIF viewer inside another react app, you may use `installViewer` as follows:
+```
+import { installViewer } from '@ohif/viewer'
+
+const ohifViewerConfig = window.config // or set it here
+const containerId = 'ohif'
+const componentRenderedOrUpdatedCallback = function() {
+    console.log('OHIF Viewer rendered/updated');
+};
+
+componentDidMount() {
+   installViewer(
+      ohifViewerConfig,
+      containerId,
+      componentRenderedOrUpdatedCallback
+    );
+}
+
+render () {
+   ...
+   //you can render in any element you wish
+   <AnyTag id={containerId}/>
+}
+
+```
+
+`installViewer` is a convenience method that pulls in some dependencies that may
+not be compatible with existing `react` apps. `@ohif/viewer` also exports `App`
+which is a react component that takes the `configuration` outlined above as
+props. You can use it as a reusable component, and to avoid `react` version
+conflict issues.
+
+
+<!--
+  LINKS
+  -->
+
+<!-- prettier-ignore-start -->
+[code-sandbox]: https://codesandbox.io/s/viewer-script-tag-tprch
+[whole-slide-base-demo]: https://tprch.csb.app/viewer/1.2.392.200140.2.1.1.1.2.799008771.2020.1519719354.757
+[ext-code-sandbox]: https://codesandbox.io/s/viewer-script-tag-microscopy-extension-44unk
+[whole-slide-ext-demo]: https://44unk.csb.app/viewer/1.2.392.200140.2.1.1.1.2.799008771.2448.1519719572.518
+<!-- prettier-ignore-end -->

docs/v2/deployment/recipes/nginx--image-archive.md

@@ -0,0 +1,242 @@
+# Nginx + Image Archive
+
+> DISCLAIMER! We make no claims or guarantees of this approach's security. If in
+> doubt, enlist the help of an expert and conduct proper audits.
+
+At a certain point, you may want others to have access to your instance of the
+OHIF Viewer and its medical imaging data. This post covers one of many potential
+setups that accomplish that. Please note, noticably absent is user account
+control.
+
+Do not use this recipe to host sensitive medical data on the open web. Depending
+on your company's policies, this may be an appropriate setup on an internal
+network when protected with a server's basic authentication. For a more robust
+setup, check out our [user account control recipe](./user-account-control.md)
+that builds on the lessons learned here.
+
+## Overview
+
+Our two biggest hurdles when hosting our image archive and web client are:
+
+- Risks related to exposing our PACS to the netowrk
+- Cross-Origin Resource Sharing (CORS) requests
+
+### Handling Web Requests
+
+We mittigate our first issue by allowing [Nginx][nginx] to handle incoming web
+requests. Nginx is open source software for web serving, reverse proxying,
+caching, and more. It's designed for maximum performance and stability --
+allowing us to more reliably serve content than Orthanc's built-in server can.
+
+More specifically, we accomplish this by using a
+[`reverse proxy`](https://en.wikipedia.org/wiki/Reverse_proxy) to retrieve
+resources from our image archive (Orthanc), and when accessing its web admin.
+
+> A reverse proxy is a type of proxy server that retrieves resources on behalf
+> of a client from one or more servers. These resources are then returned to the
+> client, appearing as if they originated from the proxy server itself.
+
+### CORS Issues
+
+Cross-Origin Resource Sharing (CORS) is a mechanism that uses HTTP headers to
+tell a browser which web applications have permission to access selected
+resources from a server at a different origin (domain, protocol, port). IE. By
+default, a Web App located at `http://my-website.com` can't access resources
+hosted at `http://not-my-website.com`
+
+We can solve this one of two ways:
+
+1. Have our Image Archive located at the same domain as our Web App
+2. Add appropriate `Access-Control-Allow-*` HTTP headers
+
+**This solution uses the first approach.**
+
+You can read more about CORS in this Medium article: [Understanding
+CORS][understanding-cors]
+
+### Diagram
+
+This setup allows us to create a setup similar to the one pictured below:
+
+{% include "./../_nginx-image-archive-diagram.md" %}
+
+- All web requests are routed through `nginx` on our `OpenResty` image
+- `/pacs` is a reverse proxy for `orthanc`'s `DICOM Web` endpoints
+- `/pacs-admin` is a reverse proxy for `orthanc`'s Web Admin
+- All static resources for OHIF Viewer are served up by `nginx` when a matching
+  route for that resource is requested
+
+## Getting Started
+
+### Requirements
+
+- Docker
+  - [Docker for Mac](https://docs.docker.com/docker-for-mac/)
+  - [Docker for Windows](https://docs.docker.com/docker-for-windows/)
+
+_Not sure if you have `docker` installed already? Try running `docker --version`
+in command prompt or terminal_
+
+### Setup
+
+_Spin Things Up_
+
+- Navigate to `<project-root>/docker/OpenResty-Orthanc` in your shell
+- Run `docker-compose up`
+
+_Upload Your First Study_
+
+- Navigate to `http://127.0.0.1/pacs-admin`
+- From the top right, select "Upload"
+- Click "Select files to upload..." (DICOM)
+- Click "Start the upload"
+- Navigate back to `http://127.0.0.1/` to view your studies in the Study List
+
+### Troubleshooting
+
+_Exit code 137_
+
+This means Docker ran out of memory. Open Docker Desktop, go to the `advanced`
+tab, and increase the amount of Memory available.
+
+_Cannot create container for service X_
+
+Use this one with caution: `docker system prune`
+
+_X is already running_
+
+Stop running all containers:
+
+- Win: `docker ps -a -q | ForEach { docker stop $_ }`
+- Linux: `docker stop $(docker ps -a -q)`
+
+### Configuration
+
+After verifying that everything runs with default configuration values, you will
+likely want to update:
+
+- The domain: `http://127.0.0.1`
+
+#### OHIF Viewer
+
+The OHIF Viewer's configuration is imported from a static `.js` file. The
+configuration we use is set to a specific file when we build the viewer, and
+determined by the env variable: `APP_CONFIG`. You can see where we set its value
+in the `dockerfile` for this solution:
+
+`ENV APP_CONFIG=config/docker_openresty-orthanc.js`
+
+You can find the configuration we're using here:
+`/public/config/docker_openresty-orthanc.js`
+
+To rebuild the `webapp` image created by our `dockerfile` after updating the
+Viewer's configuration, you can run:
+
+- `docker-compose build` OR
+- `docker-compose up --build`
+
+#### Other
+
+All other files are found in: `/docker/OpenResty-Orthanc/`
+
+| Service           | Configuration                     | Docs                                        |
+| ----------------- | --------------------------------- | ------------------------------------------- |
+| OHIF Viewer       | [dockerfile][dockerfile]          | You're reading them now!                    |
+| OpenResty (Nginx) | [`/nginx.conf`][config-nginx]     | [lua-resty-openidc][lua-resty-openidc-docs] |
+| Orthanc           | [`/orthanc.json`][config-orthanc] | [Here][orthanc-docs]                        |
+
+## Next Steps
+
+### Deploying to Production
+
+While these configuration and docker-compose files model an environment suitable
+for production, they are not easy to deploy "as is". You can either:
+
+- Manually recreate this environment and deploy built application files **OR**
+- Deploy to a cloud kubernetes provider like
+  [Digital Ocean](https://www.digitalocean.com/products/kubernetes/) **OR**
+  - [See a full list of cloud providers here](https://landscape.cncf.io/category=cloud&format=card-mode&grouping=category)
+- Find and follow your preferred provider's guide on setting up
+  [swarms and stacks](https://docs.docker.com/get-started/)
+
+### Adding SSL
+
+Adding SSL registration and renewal for your domain with Let's Encrypt that
+terminates at Nginx is an incredibly important step toward securing your data.
+Here are some resources, specific to this setup, that may be helpful:
+
+- [lua-resty-auto-ssl](https://github.com/GUI/lua-resty-auto-ssl)
+- [Let's Encrypt + Nginx](https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/)
+
+While we terminate SSL at Nginx, it may be worth using self signed certificates
+for communication between services.
+
+- [SSL Termination for TCP Upstream Servers](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-tcp/)
+
+### Use PostgresSQL w/ Orthanc
+
+Orthanc can handle a large amount of data and requests, but if you find that
+requests start to slow as you add more and more studies, you may want to
+configure your Orthanc instance to use PostgresSQL. Instructions on how to do
+that can be found in the
+[`Orthanc Server Book`](http://book.orthanc-server.com/users/docker.html), under
+"PostgreSQL and Orthanc inside Docker"
+
+### Improving This Guide
+
+Here are some improvements this guide would benefit from, and that we would be
+more than happy to accept Pull Requests for:
+
+- SSL Support
+- Complete configuration with `.env` file (or something similar)
+- Any security issues
+- One-click deploy to a cloud provider
+
+## Resources
+
+### Misc. Helpful Commands
+
+_Check if `nginx.conf` is valid:_
+
+```bash
+docker run --rm -t -a stdout --name my-openresty -v $PWD/config/:/usr/local/openresty/nginx/conf/:ro openresty/openresty:alpine-fat openresty -c /usr/local/openresty/nginx/conf/nginx.conf -t
+```
+
+_Interact w/ running container:_
+
+`docker exec -it CONTAINER_NAME bash`
+
+_List running containers:_
+
+`docker ps`
+
+### Referenced Articles
+
+For more documentation on the software we've chosen to use, you may find the
+following resources helpful:
+
+- [Orthanc for Docker](http://book.orthanc-server.com/users/docker.html)
+- [OpenResty Guide](http://www.staticshin.com/programming/definitely-an-open-resty-guide/)
+- [Lua Ngx API](https://openresty-reference.readthedocs.io/en/latest/Lua_Nginx_API/)
+
+For a different take on this setup, check out the repositories our community
+members put together:
+
+- [mjstealey/ohif-orthanc-dimse-docker](https://github.com/mjstealey/ohif-orthanc-dimse-docker)
+- [trypag/ohif-orthanc-postgres-docker](https://github.com/trypag/ohif-orthanc-postgres-docker)
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+<!-- DOCS -->
+[nginx]: https://www.nginx.com/resources/glossary/nginx/
+[understanding-cors]: https://medium.com/@baphemot/understanding-cors-18ad6b478e2b
+[orthanc-docs]: http://book.orthanc-server.com/users/configuration.html#configuration
+[lua-resty-openidc-docs]: https://github.com/zmartzone/lua-resty-openidc
+<!-- SRC -->
+[dockerfile]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc/dockerfile
+[config-nginx]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc/config/nginx.conf
+[config-orthanc]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc/config/orthanc.json
+<!-- prettier-ignore-end -->

docs/v2/deployment/recipes/static-assets.md

@@ -0,0 +1,149 @@
+# Deploy Static Assets
+
+> WARNING! All of these solutions stand-up a publicly accessible web viewer. Do
+> not hook your hosted viewer up to a sensitive source of data without
+> implementing authentication.
+
+There are a lot of options for deploying static assets. Some services, like
+`netlify` and `surge.sh`, specialize in static websites. You'll notice that
+deploying with them requires much less time and effort, but comes at the cost of
+less product offerings.
+
+While not required, it can simplify things to host your Web Viewer alongside
+your image archive. Services with more robust product offerings, like
+`Google Cloud`, `Microsoft's Azure`, and `Amazon Web Services (AWS)`, are able
+to accomodate this setup.
+
+_Drag-n-drop_
+
+- [Netlify: Drop](#netlify-drop)
+
+_Easy_
+
+- [Surge.sh](#surgesh)
+- [GitHub Pages](#github-pages)
+
+_Advanced_
+
+- [AWS S3 + Cloudfront](#aws-s3--cloudfront)
+- [GCP + Cloudflare](#gcp--cloudflare)
+- [Azure](#azure)
+
+## Drag-n-drop
+
+### Netlify: Drop
+
+> Build, deploy, and manage modern web projects. An all-in-one workflow that
+> combines global deployment, continuous integration, and automatic HTTPS. And
+> that’s just the beginning.
+
+![netlify-drop example](../../assets/img/netlify-drop.gif)
+
+_GIF demonstrating deployment with Netlify Drop_
+
+1. https://app.netlify.com/drop
+2. Drag your `build/` folder on to the drop target
+3. ...
+4. _annnd you're done_
+
+**Features:**
+
+- Custom domains & HTTPS
+- Instant Git integration
+- Continuous deployment
+- Deploy previews
+- Access to add-ons
+
+(Non-free tiers include identity, FaaS, Forms, etc.)
+
+Learn more about [Netlify on their website](https://www.netlify.com/)
+
+## Easy
+
+### Surge.sh
+
+> Static web publishing for Front-End Developers. Simple, single-command web
+> publishing. Publish HTML, CSS, and JS for free, without leaving the command
+> line.
+
+![surge.sh deploy example](../../assets/img/surge-deploy.gif)
+
+_GIF demonstrating deployment with surge_
+
+```shell
+# Add surge command
+yarn global add surge
+
+# In the build directory
+surge
+```
+
+**Features:**
+
+- Free custom domain support
+- Free SSL for surge.sh subdomains
+- pushState support for single page apps
+- Custom 404.html pages
+- Barrier-free deployment through the CLI
+- Easy integration into your Grunt toolchain
+- Cross-origin resource support
+- And more…
+
+Learn more about [surge.sh on their website](https://surge.sh/)
+
+### GitHub Pages
+
+> WARNING! While great for project sites and light use, it is not advised to use
+> GitHub Pages for production workloads. Please consider using a different
+> service for mission critical applications.
+
+> Websites for you and your projects. Hosted directly from your GitHub
+> repository. Just edit, push, and your changes are live.
+
+This deploy strategy makes more sense if you intend to maintain your project in
+a GitHub repository. It allows you to specify a `branch` or `folder` as the
+target for a GitHub Page's website. As you push code changes, the hosted content
+updates to reflect those changes.
+
+1. Head over to GitHub.com and create a new repository, or go to an existing
+   one. Click on the Settings tab.
+2. Scroll down to the GitHub Pages section. Choose the `branch` or `folder` you
+   would like as the "root" of your website.
+3. Fire up a browser and go to `http://username.github.io/repository`
+
+Configuring Your Site:
+
+- [Setting up a custom domain](https://help.github.com/en/articles/using-a-custom-domain-with-github-pages)
+- [Setting up SSL](https://help.github.com/en/articles/securing-your-github-pages-site-with-https)
+
+Learn more about [GitHub Pages on its website](https://pages.github.com/)
+
+## Advanced
+
+All of these options, while using providers with more service offerings,
+demonstrate how to host the viewer with their respective file storage and CDN
+offerings. While you can serve your static assets this way, if you're going
+through the trouble of using AWS/GCP/Azure, it's more likely you're doing so to
+avoid using a proxy or to simplify authentication.
+
+If that is the case, check out some of our more advanced `docker` deployments
+that target these providers from the left-hand sidepanel.
+
+These guides can be a bit longer and a update more frequently. To provide
+accurate documentation, we will link to each provider's own recommended steps:
+
+### AWS S3 + Cloudfront
+
+- [Host a Static Website](https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html)
+- [Speed Up Your Website with Cloudfront](https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-cloudfront-walkthrough.html)
+
+### GCP + Cloudflare
+
+- [Things to Know Before Getting Started](https://code.luasoftware.com/tutorials/google-cloud-storage/things-to-know-before-hosting-static-website-on-google-cloud-storage/)
+- [Hosting a Static Website on GCP](https://cloud.google.com/storage/docs/hosting-static-website)
+
+### Azure
+
+- [Host a Static Website](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website)
+- [Add SSL Support](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-https-custom-domain-cdn)
+- [Configure a Custom Domain](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-custom-domain-name)

docs/v2/deployment/recipes/user-account-control.md

@@ -0,0 +1,288 @@
+# User Account Control
+
+> DISCLAIMER! We make no claims or guarantees of this approach's security. If in
+> doubt, enlist the help of an expert and conduct proper audits.
+
+Making a viewer and its medical imaging data accessible on the open web can
+provide a lot of benefits, but requires additional security to make sure
+sensitive information can only be viewed by authorized individuals. Most image
+archives are equipped with basic security measures, but they are not
+robust/secure enough for the open web.
+
+This guide covers one of many potential production setups that secure our
+sensitive data.
+
+## Overview
+
+This guide builds on top of our
+[Nginx + Image Archive guide](/deployment/recipes/nginx--image-archive.md),
+wherein we used a [`reverse proxy`](https://en.wikipedia.org/wiki/Reverse_proxy)
+to retrieve resources from our image archive (Orthanc).
+
+To add support for "User Account Control" we introduce
+[Keycloak](https://www.keycloak.org/about.html). Keycloak is an open source
+Identity and Access Management solution that makes it easy to secure
+applications and services with little to no code. We improve upon our
+`reverse proxy` setup by integrating Keycloak and Nginx to create an
+`authenticating reverse proxy`.
+
+> An authenticating reverse proxy is a reverse proxy that only retrieves the
+> resources on behalf of a client if the client has been authenticated. If a
+> client is not authenticated they can be redirected to a login page.
+
+This setup allows us to create a setup similar to the one pictured below:
+
+{% include "./../_user-account-control-flow-diagram.md" %}
+
+- All web requests are routed through `nginx` on our `OpenResty` image
+- `/pacs` is a reverse proxy for `orthanc`'s `DICOM Web` endpoints
+  - Requires valid `Authorization: Bearer <token>` header
+- `/pacs-admin` is a reverse proxy for `orthanc`'s Web Admin
+- `/auth` is a reverse proxy for `keycloak`
+- All static resources for OHIF Viewer are unprotected and accessible. We have
+  application logic that will redirect unauthenticated users to the appropriate
+  `keycloak` login screen.
+
+## Getting Started
+
+### Requirements
+
+- Docker
+  - [Docker for Mac](https://docs.docker.com/docker-for-mac/)
+  - [Docker for Windows](https://docs.docker.com/docker-for-windows/)
+
+_Not sure if you have `docker` installed already? Try running `docker --version`
+in command prompt or terminal_
+
+### Setup
+
+_Spin Things Up_
+
+- Navigate to `<project-root>/docker/OpenResty-Orthanc-Keycloak` in your shell
+- Run `docker-compose up`
+
+_Create Your First User_
+
+- Navigate to: `http://127.0.0.1/auth/admin`
+- Sign in with: `admin`/`password`
+- From the top left dropdown, select the `Ohif` realm
+- From the left sidebar, under `Manage`, select `Users`
+- Click `Add User`
+  - Username: `test`
+  - Email Verified: `ON`
+  - Click `Save`
+- Click the `Credentials` Tab
+  - New Pasword: `test`
+  - Password Confirmation: `test`
+  - Temporary: `OFF`
+  - Click: `Reset Password`
+- From the top right dropdown, select `Admin`, then `Sign Out`
+
+_Sign In_
+
+- Navigate to `http://127.0.0.1/`
+- Username: `test`, Password: `test`
+- Click `Log In`
+
+_Upload Your First Study_
+
+- Navigate to `http://127.0.0.1/pacs-admin`
+- If you're not already logged in, use `test`/`test`
+- From the top right, select "Upload"
+- Click "Select files to upload..." (DICOM)
+- Click "Start the upload"
+- Navigate back to `http://127.0.0.1/` to view your studies in the Study List
+
+### Troubleshooting
+
+_Exit code 137_
+
+This means Docker ran out of memory. Open Docker Desktop, go to the `advanced`
+tab, and increase the amount of Memory available.
+
+_Cannot create container for service X_
+
+Use this one with caution: `docker system prune`
+
+_X is already running_
+
+Stop running all containers:
+
+- Win: `docker ps -a -q | ForEach { docker stop $_ }`
+- Linux: `docker stop $(docker ps -a -q)`
+
+### Configuration
+
+After verifying that everything runs with default configuration values, you will
+likely want to update:
+
+- The domain: `http://127.0.0.1`
+- Set secure, non-default passwords
+- Regenerate Keycloak Client Secrets
+
+#### OHIF Viewer
+
+The OHIF Viewer's configuration is imported from a static `.js` file. The
+configuration we use is set to a specific file when we build the viewer, and
+determined by the env variable: `APP_CONFIG`. You can see where we set its value
+in the `dockerfile` for this solution:
+
+`ENV APP_CONFIG=config/docker_openresty-orthanc-keycloak.js`
+
+You can find the configuration we're using here:
+`/public/config/docker_openresty-orthanc-keycloak.js`
+
+To rebuild the `webapp` image created by our `dockerfile` after updating the
+Viewer's configuration, you can run:
+
+- `docker-compose build` OR
+- `docker-compose up --build`
+
+#### Other
+
+All other files are found in: `/docker/OpenResty-Orthanc-Keycloak/`
+
+| Service           | Configuration                                    | Docs                                        |
+| ----------------- | ------------------------------------------------ | ------------------------------------------- |
+| OHIF Viewer       | [dockerfile][dockerfile] / [config.js][config]   | You're reading them now!                    |
+| OpenResty (Nginx) | [`/nginx.conf`][config-nginx]                    | [lua-resty-openidc][lua-resty-openidc-docs] |
+| Orthanc           | [`/orthanc.json`][config-orthanc]                | [Here][orthanc-docs]                        |
+| Keycloak          | [`/ohif-keycloak-realm.json`][config-keycloak]\* |                                             |
+
+\* These are the seed values for Keycloak. They can be manually updated at
+`http://127.0.0.1/auth/admin`
+
+#### Keycloak Themeing
+
+The `Login` screen for the `ohif-viewer` client is using a Custom Keycloak
+theme. You can find the source files for it in
+`/docker/OpenResty-Orthanc-Keycloak/volumes/keycloak-themes/`. You can see how
+we add it to Keycloak in the `docker-compose` file, and you can read up on how
+to leverage custom themes in
+[Keycloak's own docs](https://www.keycloak.org/docs/latest/server_development/index.html#_themes).
+
+| Default Theme                                                          | OHIF Theme                                                       |
+| ---------------------------------------------------------------------- | ---------------------------------------------------------------- |
+| ![Keycloak Default Theme](../../assets/img/keycloak-default-theme.png) | ![Keycloak OHIF Theme](../../assets/img/keycloak-ohif-theme.png) |
+
+## Next Steps
+
+### Deploying to Production
+
+While these configuration and docker-compose files model an environment suitable
+for production, they are not easy to deploy "as is". You can either:
+
+- Manually recreate this environment and deploy built application files **OR**
+- Deploy to a cloud kubernetes provider like
+  [Digital Ocean](https://www.digitalocean.com/products/kubernetes/) **OR**
+  - [See a full list of cloud providers here](https://landscape.cncf.io/category=cloud&format=card-mode&grouping=category)
+- Find and follow your preferred provider's guide on setting up
+  [swarms and stacks](https://docs.docker.com/get-started/)
+
+### Adding SSL
+
+Adding SSL registration and renewal for your domain with Let's Encrypt that
+terminates at Nginx is an incredibly important step toward securing your data.
+Here are some resources, specific to this setup, that may be helpful:
+
+- [lua-resty-auto-ssl](https://github.com/GUI/lua-resty-auto-ssl)
+- [Let's Encrypt + Nginx](https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/)
+
+While we terminate SSL at Nginx, it may be worth using self signed certificates
+for communication between services.
+
+- [SSL Termination for TCP Upstream Servers](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-tcp/)
+
+### Use PostgresSQL w/ Orthanc
+
+Orthanc can handle a large amount of data and requests, but if you find that
+requests start to slow as you add more and more studies, you may want to
+configure your Orthanc instance to use PostgresSQL. Instructions on how to do
+that can be found in the
+[`Orthanc Server Book`](http://book.orthanc-server.com/users/docker.html), under
+"PostgreSQL and Orthanc inside Docker"
+
+### Improving This Guide
+
+Here are some improvements this guide would benefit from, and that we would be
+more than happy to accept Pull Requests for:
+
+- SSL Support
+- Complete configuration with `.env` file (or something similar)
+- Keycloak Theme improvements
+- Any security issues
+- One-click deploy to a cloud provider
+
+## Resources
+
+### Misc. Helpful Commands
+
+_Check if `nginx.conf` is valid:_
+
+```bash
+docker run --rm -t -a stdout --name my-openresty -v $PWD/config/:/usr/local/openresty/nginx/conf/:ro openresty/openresty:alpine-fat openresty -c /usr/local/openresty/nginx/conf/nginx.conf -t
+```
+
+_Interact w/ running container:_
+
+`docker exec -it CONTAINER_NAME bash`
+
+_List running containers:_
+
+`docker ps`
+
+_Clear Keycloak DB so you can re-seed values:_
+
+- `docker volume prune` OR
+- `docker volume ls` and `docker volume rm VOLUME_NAME VOLUME_NAME`
+
+### Referenced Articles
+
+The inspiration for our setup was driven largely by these articles:
+
+- [Securing Nginx with Keycloak](https://edhull.co.uk/blog/2018-06-06/keycloak-nginx)
+- [Authenticating Reverse Proxy with Keycloak](https://eclipsesource.com/blogs/2018/01/11/authenticating-reverse-proxy-with-keycloak/)
+- [Securing APIs with Kong and Keycloak](https://www.jerney.io/secure-apis-kong-keycloak-1/)
+
+For more documentation on the software we've chosen to use, you may find the
+following resources helpful:
+
+- [Orthanc for Docker](http://book.orthanc-server.com/users/docker.html)
+- [OpenResty Guide](http://www.staticshin.com/programming/definitely-an-open-resty-guide/)
+- [Lua Ngx API](https://openresty-reference.readthedocs.io/en/latest/Lua_Nginx_API/)
+- [Auth0: Picking a Grant Type](https://auth0.com/docs/api-auth/which-oauth-flow-to-use)
+
+We chose to use a generic OpenID Connect library on the client, but it's worth
+noting that Keycloak comes packaged with its own:
+
+- [redux-oidc](https://github.com/maxmantz/redux-oidc) (Which wraps
+  [oidc-client-js](https://github.com/IdentityModel/oidc-client-js/wiki))
+- [Keycloak JavaScript Adapter](https://www.keycloak.org/docs/latest/securing_apps/index.html#_javascript_adapter)
+
+If you're not already drowning in links, here are some good security resources
+for OAuth:
+
+- [Diagrams of OpenID Connect Flows](https://medium.com/@darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660)
+- [KeyCloak: OpenID Connect Flows](https://www.keycloak.org/docs/latest/securing_apps/index.html#authorization-code)
+
+For a different take on this setup, check out the repositories our community
+members put together:
+
+- [mjstealey/ohif-orthanc-dimse-docker](https://github.com/mjstealey/ohif-orthanc-dimse-docker)
+- [trypag/ohif-orthanc-postgres-docker](https://github.com/trypag/ohif-orthanc-postgres-docker)
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+<!-- DOCS -->
+[orthanc-docs]: http://book.orthanc-server.com/users/configuration.html#configuration
+[lua-resty-openidc-docs]: https://github.com/zmartzone/lua-resty-openidc
+<!-- SRC -->
+[config]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/src/config.js
+[dockerfile]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc-Keycloak/dockerfile
+[config-nginx]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc-Keycloak/config/nginx.conf
+[config-orthanc]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc-Keycloak/config/orthanc.json
+[config-keycloak]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc-Keycloak/config/ohif-keycloak-realm.json
+<!-- prettier-ignore-end -->

docs/v2/development/continous-integration.md

@@ -0,0 +1,109 @@
+# Continous Integration (CI)
+
+This repository uses `CircleCI` and `Netlify` for continous integration.
+
+## Deploy Previews
+
+[Netlify Deploy previews][deploy-previews] are generated for every pull request.
+They allow pull request authors and reviewers to "Preview" the OHIF Viewer as if
+the changes had been merged.
+
+Deploy previews can be configured by modifying the `netlify.toml` file in the
+root of the repository. Some additional scripts/assets for netlify are included
+in the root `.netlify` directory.
+
+## Workflows
+
+[CircleCI Workflows][circleci-workflows] are a set of rules for defining a
+collection of jobs and their run order. They are self-documenting and their
+configuration can be found in our CircleCI configuration file:
+`.circleci/config.yml`.
+
+### Workflow: PR_CHECKS
+
+The PR_CHECKS workflow (Pull Request Checks) runs our automated unit and
+end-to-end tests for every code check-in. These tests must all pass before code
+can be merged to our `master` branch.
+
+<div style="text-align: center;">
+  <a href="/assets/img/WORKFLOW_PR_CHECKS.png">
+    <img src="/assets/img/WORKFLOW_PR_CHECKS.png" alt="workflow diagram" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>Workflow diagram for PR_CHECKS</i></div>
+</div>
+
+### Workflow: PR_OPTIONAL_DOCKER_PUBLISH
+
+The PR_OPTIONAL_DOCKER_PUBLISH workflow allows for "manual approval" to publish
+the pull request as a tagged docker image. This is helpful when changes need to
+be tested with the Google Adapter before merging to `master`.
+
+<div style="text-align: center;">
+  <a href="/assets/img/WORKFLOW_PR_OPTIONAL_DOCKER_PUBLISH.png">
+    <img src="/assets/img/WORKFLOW_PR_OPTIONAL_DOCKER_PUBLISH.png" alt="workflow diagram" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>Workflow diagram for PR_WORKFLOW_PR_OPTIONAL_DOCKER_PUBLISH</i></div>
+</div>
+
+> NOTE: This workflow will fail unless it's for a branch on our `upstream`
+> repository. If you need this functionality, but the branch is from a fork,
+> merge the changes to a short-lived `feature/` branch on `upstream`
+
+### Workflow: DEPLOY
+
+The DEPLOY workflow deploys the OHIF Viewer when changes are merged to master.
+It uses the Netlify CLI to deploy assets created as part of the repository's PWA
+Build process (`yarn run build`). The workflow allows for "Manual Approval" to
+promote the build to `STAGING` and `PRODUCTION` environments.
+
+<div style="text-align: center;">
+  <a href="/assets/img/WORKFLOW_DEPLOY.png">
+    <img src="/assets/img/WORKFLOW_DEPLOY.png" alt="workflow diagram" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>Workflow diagram for WORKFLOW_DEPLOY</i></div>
+</div>
+
+| Environment | Description                                                                        | URL                                           |
+| ----------- | ---------------------------------------------------------------------------------- | --------------------------------------------- |
+| Development | Always reflects latest changes on `master` branch.                                 | [Netlify][netlify-dev] / [OHIF][ohif-dev]     |
+| Staging     | For manual testing before promotion to prod. Keeps development workflow unblocked. | [Netlify][netlify-stage] / [OHIF][ohif-stage] |
+| Production  | Stable, tested, updated less frequently.                                           | [Netlify][netlify-prod] / [OHIF][ohif-prod]   |
+
+### Workflow: RELEASE
+
+The RELEASE workflow publishes our `npm` packages, updated documentation, and
+`docker` image when changes are merged to master. `Lerna` and "Semantic Commit
+Syntax" are used to independently version and publish the many packages in our
+monorepository. If a new version is cut/released, a Docker image is created.
+Documentation is generated with `gitbook` and pushed to our `gh-pages` branch.
+GitHub hosts the `gh-pages` branch with GitHub Pages.
+
+- Platform Packages: https://github.com/ohif/viewers/#platform
+- Extension Packages: https://github.com/ohif/viewers/#extensions
+- Documentation: https://docs.ohif.org/
+
+<div style="text-align: center;">
+  <a href="/assets/img/WORKFLOW_RELEASE.png">
+    <img src="/assets/img/WORKFLOW_RELEASE.png" alt="workflow diagram" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>Workflow diagram for WORKFLOW_RELEASE</i></div>
+</div>
+
+### HOTFIX
+
+_Not yet implemented_
+
+<!--
+  LINKS
+-->
+
+<!-- prettier-ignore-start -->
+[deploy-previews]: https://www.netlify.com/blog/2016/07/20/introducing-deploy-previews-in-netlify/
+[circleci-workflows]: https://circleci.com/docs/2.0/workflows/
+[netlify-dev]: https://ohif-dev.netlify.com
+[netlify-stage]: https://ohif-stage.netlify.com
+[netlify-prod]: https://ohif-prod.netlify.com
+[ohif-dev]: https://viewer-dev.ohif.org
+[ohif-stage]: https://viewer-stage.ohif.org
+[ohif-prod]: https://viewer-prod.ohif.org
+<!-- prettier-ignore-end -->

docs/v2/development/contributing.md

@@ -0,0 +1,146 @@
+# Contributing
+
+## How can I help?
+
+Fork the repository, make your change and submit a pull request. If you would
+like to discuss the changes you intend to make to clarify where or how they
+should be implemented, please don't hesitate to create a new issue. At a
+minimum, you may want to read the following documentation:
+
+- [Getting Started](/development/getting-started.md)
+- [Architecture](/architecture/index.md)
+
+Pull requests that are:
+
+- Small
+- [Well tested](./testing.md)
+- Decoupled
+
+Are much more likely to get reviewed and merged in a timely manner.
+
+## When changes impact multiple repositories
+
+While this can be tricky, we've tried to reduce how often this situation crops
+up this with our [recent switch to a monorepo][monorepo]. Our maintained
+extensions, ui components, internationalization library, and business logic can
+all be developed by simply running `yarn run dev` from the repository root.
+
+Testing the viewer with locally developed, unpublished package changes from a
+package outside of the monorepo is most common with extension development. Let's
+demonstrate how to accomplish this with two commonly forked extension
+dependencies:
+
+### `cornerstone-tools`
+
+On your local file system:
+
+```bash
+# code/my-projects/
+.
+├── cornerstonejs/cornerstone-tools
+└── ohif/viewers
+```
+
+- Open a terminal/shell
+- Navigate to `cornerstonejs/cornerstone-tools`
+  - `npm install`
+  - [`yarn link`](https://yarnpkg.com/en/docs/cli/link)
+  - `npm run dev`
+- Open a new terminal/shell
+- Navigate to `ohif/viewers`.
+  - `yarn install`
+  - [`yarn link cornerstone-tools`](https://yarnpkg.com/en/docs/cli/link)
+  - `yarn run dev`
+
+As you make changed to `cornerstone-tools`, and it's output is rebuilt, you
+should see the following behavior:
+
+<div style="text-align: center;">
+  <a href="/assets/img/cornerstone-tools-link.gif">
+    <img src="/assets/img/cornerstone-tools-link.gif" alt="Example of linked cornerstone-tools package" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>example of linked cornerstone-tools package</i></div>
+</div>
+
+If you wish to stop using your local package, run the following commands in the
+`ohif/viewers` repository root:
+
+- `yarn unlink cornerstone-tools`
+- `yarn install --force`
+
+### `react-vtkjs-viewport`
+
+On your local file system:
+
+```bash
+# code/my-projects/
+.
+├── ohif/react-vtkjs-viewport
+└── ohif/viewers
+```
+
+- Open a terminal/shell
+- Navigate to `ohif/react-vtkjs-viewport`
+  - `yarn install`
+  - [`yarn link`](https://yarnpkg.com/en/docs/cli/link)
+  - `yarn run start`
+- Open a new terminal/shell
+- Navigate to `ohif/viewers`.
+  - `yarn install`
+  - [`yarn link react-vtkjs-viewport`](https://yarnpkg.com/en/docs/cli/link)
+  - `yarn run dev`
+
+#### Other linkage notes
+
+We're still working out some of the kinks with local package development as
+there are a lot of factors that can influence the behavior of our development
+server and bundler. If you encounter issues not addressed here, please don't
+hesitate to reach out on GitHub.
+
+## Any guidance on submitting changes?
+
+While we do appreciate code contributions, triaging and integrating contributed
+code changes can be very time consuming. Please consider the following tips when
+working on your pull requests:
+
+- Functionality is appropriate for the repository. Consider creating a GitHub
+  issue to discuss your suggested changes.
+- The scope of the pull request is not too large. Please consider separate pull
+  requests for each feature as big pull requests are very time consuming to
+  understand.
+
+We will provide feedback on your pull requests as soon as possible. Following
+the tips above will help ensure your changes are reviewed.
+
+## Testing contribution pull requests
+
+OHIF uses [netlify](https://www.netlify.com/) so that pull requests are
+autogenerated and available for testing.
+
+For example, [this url][example-url] allows you to test [pull request 237, the
+request that created this FAQ entry,][pr-237] using data pulled from Amazon S3.
+
+Replacing the number 237 in the link below with your pull request number should
+let you test it as well and you can use this link for discussions on github
+without requiring reviewers to download and build your branch.
+
+```bash
+https://deploy-preview-237--ohif.netlify.com/viewer/?url=https://s3.eu-central-1.amazonaws.com/ohif-viewer/sampleDICOM.json
+```
+
+If you have made a documentation change, a link like this will let you preview
+the gitbook generated by the pull request:
+
+```bash
+https://deploy-preview-237--ohif.netlify.com/contributing.html
+```
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[example-url]: https://deploy-preview-237--ohif.netlify.com/viewer/?url=https://s3.eu-central-1.amazonaws.com/ohif-viewer/sampleDICOM.json
+[pr-237]: https://github.com/OHIF/Viewers/pull/237
+[monorepo]: https://github.com/OHIF/Viewers/issues/768
+<!-- prettier-ignore-end -->

docs/v2/development/getting-started.md

@@ -0,0 +1,107 @@
+# Getting Started
+
+## Setup
+
+### Fork & Clone
+
+If you intend to contribute back changes, or if you would like to pull updates
+we make to the OHIF Viewer, then follow these steps:
+
+- [Fork][fork-a-repo] the [OHIF/Viewers][ohif-viewers-repo] repository
+- [Create a local clone][clone-a-repo] of your fork
+  - `git clone https://github.com/YOUR-USERNAME/Viewers`
+- Add OHIF/Viewers as a [remote repository][add-remote-repo] labled `upstream`
+  - Navigate to the cloned project's directory
+  - `git remote add upstream https://github.com/OHIF/Viewers.git`
+
+With this setup, you can now [sync your fork][sync-changes] to keep it
+up-to-date with the upstream (original) repository. This is called a "Triangular
+Workflow" and is common for Open Source projects. The GitHub blog has a [good
+graphic that illustrates this setup][triangular-workflow].
+
+### Private
+
+Alternatively, if you intend to use the OHIF Viewer as a starting point, and you
+aren't as concerned with syncing updates, then follow these steps:
+
+1. Navigate to the [OHIF/Viewers][ohif-viewers] repository
+2. Click `Clone or download`, and then `Download ZIP`
+3. Use the contents of the `.zip` file as a starting point for your viewer
+
+> NOTE: It is still possible to sync changes using this approach. However,
+> submitting pull requests for fixes and features are best done with the
+> separate, forked repository setup described in "Fork & Clone"
+
+## Developing
+
+### Requirements
+
+- [Node.js & NPM](https://nodejs.org/en/)
+- [Yarn](https://yarnpkg.com/en/)
+- Yarn workspaces should be enabled:
+  - `yarn config set workspaces-experimental true`
+
+### Kick the tires
+
+Navigate to the root of the project's directory in your terminal and run the
+following commands:
+
+```bash
+# Restore dependencies
+yarn install
+
+# Start local development server
+yarn run dev
+```
+
+You should see the following output:
+
+```bash
+@ohif/viewer: i ｢wds｣: Project is running at http://localhost:3000/
+@ohif/viewer: i ｢wds｣: webpack output is served from /
+@ohif/viewer: i ｢wds｣: Content not from webpack is served from D:\code\ohif\Viewers\platform\viewer
+@ohif/viewer: i ｢wds｣: 404s will fallback to /index.html
+
+# And a list of all generated files
+```
+
+### 🎉 Celebrate 🎉
+
+<center>
+  <img alt="development server hosted app" src="/assets/img/loading-study.gif" />
+  <i>Our app, hosted by the development server</i>
+</center>
+
+### Building for Production
+
+> More comprehensive guides for building and publishing can be found in our
+> [deployment docs](./../deployment/index.md)
+
+```bash
+# Build static assets to host a PWA
+yarn run build
+
+# Build packaged output (script-tag use)
+yarn run build:package
+```
+
+## Troubleshooting
+
+- If you receive a _"No Studies Found"_ message and do not see your studies, try
+  changing the Study Date filters to a wider range.
+- If you see a 'Loading' message which never resolves, check your browser
+  JavaScript console inside the Developer Tools to identify any errors.
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[fork-a-repo]: https://help.github.com/en/articles/fork-a-repo
+[clone-a-repo]: https://help.github.com/en/articles/fork-a-repo#step-2-create-a-local-clone-of-your-fork
+[add-remote-repo]: https://help.github.com/en/articles/fork-a-repo#step-3-configure-git-to-sync-your-fork-with-the-original-spoon-knife-repository
+[sync-changes]: https://help.github.com/en/articles/syncing-a-fork
+[triangular-workflow]: https://github.blog/2015-07-29-git-2-5-including-multiple-worktrees-and-triangular-workflows/#improved-support-for-triangular-workflows
+[ohif-viewers-repo]: https://github.com/OHIF/Viewers
+[ohif-viewers]: https://github.com/OHIF/Viewers
+<!-- prettier-ignore-end -->

docs/v2/development/testing.md

@@ -0,0 +1,145 @@
+# Contributing: Tests
+
+> Testing is an opinionated topic. Here is a rough overview of our testing
+> philosiphy. See something you want to discuss or think should be changed? Open
+> a PR and let's discuss.
+
+You're an engineer. You know how to write code, and writing tests isn't all that
+different. But do you know why we write tests? Do you know when to write one, or
+what kind of test to write? How do you know if a test is a _"good"_ test? This
+document's goal is to give you the tools you need to make those determinations.
+
+Okay. So why do we write tests? To increase our... **CONFIDENCE**
+
+- If I do a large refactor, does everything still work?
+- If I changed some critical piece of code, is it safe to push to production?
+
+Gaining the confidence we need to answer these questions after every change is
+costly. Good tests allow us to answer them without manual regression testing.
+What and how we choose to test to increase that confidence is nuanced.
+
+## Kinds of Tests
+
+Test's buy us confidence, but not all tests are created equal. Each kind of test
+has a different cost to write and maintain. An expensive test is worth it if it
+gives us confidence that a payment is processed, but it may not be the best
+choice for asserting an element's border color.
+
+| Test Type   | Example                                                                  | Speed            | Cost                                                                     |
+| ----------- | ------------------------------------------------------------------------ | ---------------- | ------------------------------------------------------------------------ |
+| Static      | `addNums(1, '2')` called with `string`, expected `int`.                  | :rocket: Instant | :money_with_wings:                                                       |
+| Unit        | `addNums(1, 2)` returns expected result `3`                              | :airplane: Fast  | :money_with_wings::money_with_wings:                                     |
+| Integration | Clicking "Sign In", navigates to the dashboard (mocked network requests) | :running: Okay   | :money_with_wings::money_with_wings::money_with_wings:                   |
+| End-to-end  | Clicking "Sign In", navigates to the dashboard (no mocks)                | :turtle: Slow    | :money_with_wings::money_with_wings::money_with_wings::money_with_wings: |
+
+- :rocket: Speed: How quickly tests run
+- :money_with_wings: Cost: Time to write, and to debug when broken (more points
+  of failure)
+
+### Static Code Analysis
+
+Modern tooling gives us this "for free". It can catch invalid regular
+expressions, unused variables, and guarantee we're calling methods/functions
+with the expected paramater types.
+
+Example Tooling:
+
+- [ESLint][eslint-rules]
+- [TypeScript][typescript-docs] or [Flow][flow-org]
+
+### Unit Tests
+
+The building blocks of our libraries and applications. For these, you'll often
+be testing a single function or method. Conceptually, this equates to:
+
+_Pure Function Test:_
+
+- If I call `sum(2, 2)`, I expect the output to be `4`
+
+_Side Effect Test:_
+
+- If I call `resetViewport(viewport)`, I expect `cornerstone.reset` to be called
+  with `viewport`
+
+#### When to use
+
+Anything that is exposed as public API should have unit tests.
+
+#### When to avoid
+
+You're actually testing implementation details. You're testing implementation
+details if:
+
+- Your test does something that the consumer of your code would never do.
+  - IE. Using a private function
+- A refactor can break your tests
+
+### Integration Tests
+
+We write integration tests to gain confidence that several units work together.
+Generally, we want to mock as little as possible for these tests. In practice,
+this means only mocking network requests.
+
+#### When to use
+
+...
+
+### End-to-End Tests
+
+These are the most expensive tests to write and maintain. Largely because, when
+they fail, they have the largest number of potential points of failure. So why
+do we write them? Because they also buy us the most confidence.
+
+#### When to use
+
+Mission critical features and functionality, or to cover a large breadth of
+functionality until unit tests catch up. Unsure if we should have a test for
+feature `X` or scenario `Y`? Open an issue and let's discuss.
+
+## Summary
+
+- Does your test increase confidence?
+- Does the test type chosen balance the cost-to-confidence ratio?
+
+## Further Reading
+
+### General
+
+- [Assert(js) Conf 2018 Talks][assert-js-talks]
+  - [Write tests. Not too many. Mostly integration.][kent-talk] - Kent C. Dodds
+  - [I see your point, but…][gleb-talk] - Gleb Bahmutov
+- [Static vs Unit vs Integration vs E2E Testing][kent-blog] - Kent C. Dodds
+  (Blog)
+
+### End-to-end Testing w/ Cypress
+
+- [Getting Started](https://docs.cypress.io/guides/overview/why-cypress.html)
+  - Be sure to check out `Getting Started` and `Core Concepts`
+- [Best Practices](https://docs.cypress.io/guides/references/best-practices.html)
+- [Example Recipes](https://docs.cypress.io/examples/examples/recipes.html)
+
+## Testing Dorito
+
+[![testing dorito][testing-dorito-img]][testing-dorito]
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[eslint-rules]: https://eslint.org/docs/rules/
+[typescript-docs]: https://www.typescriptlang.org/docs/home.html
+[flow-org]: https://flow.org/
+<!-- Talks -->
+[assert-js-talks]: https://www.youtube.com/playlist?list=PLZ66c9_z3umNSrKSb5cmpxdXZcIPNvKGw
+[kent-talk]: https://www.youtube.com/watch?v=Fha2bVoC8SE
+[gleb-talk]: https://www.youtube.com/watch?v=5FnalKRjpZk
+[kent-blog]: https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests
+<!-- Images -->
+[testing-trophy]: https://twitter.com/kentcdodds/status/960723172591992832?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E960723172591992832&ref_url=https%3A%2F%2Fkentcdodds.com%2Fblog%2Fwrite-tests
+[aaron-square]: https://twitter.com/Carofine247/status/966727489274961920
+[gleb-pyramid]: https://twitter.com/Carofine247/status/966764532046684160/photo/3
+[testing-pyramid]: https://dojo.ministryoftesting.com/dojo/lessons/the-mobile-test-pyramid
+[testing-dorito]: https://twitter.com/denvercoder/status/960752578198843392
+[testing-dorito-img]: https://pbs.twimg.com/media/DVVHXycUMAAcN-F?format=jpg&name=4096x4096
+<!-- prettier-ignore-end -->

docs/v2/extensions/_maintained-extensions-table.md

@@ -0,0 +1,75 @@
+<table>
+    <thead>
+        <tr>
+            <th>Extension</th>
+            <th>Description</th>
+            <th>Modules</th>
+        </tr>
+    </thead>
+    <tbody>
+        <!-- CORNERSTONE.js -->
+        <tr>
+            <td>
+                <a href="https://www.npmjs.com/package/@ohif/extension-cornerstone">
+                    Cornerstone
+                </a>
+            </td>
+            <td>
+                A viewport powered by <code>cornerstone.js</code>. Adds support for 2D DICOM rendering and manipulation, as well as support for the tools features in <a href="https://tools.cornerstonejs.org/examples/"><code>cornerstone-tools</code></a>. Also adds "CINE Dialog" to the Toolbar.
+            </td>
+            <td>Viewport, Toolbar</td>
+        </tr>
+        <!-- VTK.js -->
+        <tr>
+            <td>
+                <a href="https://www.npmjs.com/package/@ohif/extension-vtk">
+                    VTK.js
+                </a>
+            </td>
+            <td>
+                A viewport powered by <code>vtk.js</code>. Adds support for volume renderings and advanced features like MPR. Also adds "3D Rotate" to the Toolbar.
+            </td>
+            <td>Viewport, Toolbar</td>
+        </tr>
+        <!-- dicom-html -->
+        <tr>
+            <td>
+                <a href="https://www.npmjs.com/package/@ohif/extension-dicom-html">DICOM HTML</a>
+            </td>
+            <td>
+                Renders text and HTML content for <a href="https://github.com/OHIF/Viewers/blob/master/extensions/dicom-html/src/OHIFDicomHtmlSopClassHandler.js#L4-L12">specific SopClassUIDs</a>.
+            </td>
+            <td>Viewport, SopClassHandler</td>
+        </tr>
+        <!-- dicom-pdf -->
+        <tr>
+            <td>
+                <a href="https://www.npmjs.com/package/@ohif/extension-dicom-pdf">DICOM PDF</a>
+            </td>
+            <td>
+                Renders PDFs for a <a href="https://github.com/OHIF/Viewers/blob/master/extensions/dicom-pdf/src/OHIFDicomPDFSopClassHandler.js#L4-L6">specific SopClassUID</a>.
+            </td>
+            <td>Viewport, SopClassHandler</td>
+        </tr>
+        <!-- dicom-microscopy -->
+        <tr>
+            <td>
+                <a href="https://www.npmjs.com/package/@ohif/extension-dicom-microscopy">DICOM Microscopy</a>
+            </td>
+            <td>
+                Renders Microscopy images for a <a href="https://github.com/OHIF/Viewers/blob/master/extensions/dicom-microscopy/src/DicomMicroscopySopClassHandler.js#L5-L7">specific SopClassUID</a>.
+            </td>
+            <td>Viewport, SopClassHandler</td>
+        </tr>
+        <!-- dicom-segmentation -->
+        <tr>
+            <td>
+                <a href="https://www.npmjs.com/package/@ohif/extension-dicom-segmentation">DICOM Segmentation</a>
+            </td>
+            <td>
+                Renders segmentation images for a <a href="https://github.com/OHIF/Viewers/blob/master/extensions/dicom-segmentation/src/OHIFDicomSegSopClassHandler.js#L5-L7">specific SopClassUID</a>.
+            </td>
+            <td>Panel, Toolbar</td>
+        </tr>
+    </tbody>
+</table>

docs/v2/extensions/index.md

@@ -0,0 +1,240 @@
+# Extensions
+
+- [Overview](#overview)
+- [Concepts](#concepts)
+  - [Extension Skeleton](#extension-skeleton)
+  - [Registering an Extension](#registering-an-extension)
+  - [Lifecylce Hooks](#lifecycle-hooks)
+  - [Modules](#modules)
+  - [Contexts](#contexts)
+- [Consuming Extensions](#consuming-extensions)
+  - [Extension Manager](#extensionmanager)
+- [Maintained 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. Ideally,
+they're built in a way that allows them to extend entirely different
+implementations of the `@ohif/viewer` project.
+
+<div style="text-align: center;">
+  <a href="/assets/img/extensions-diagram.png">
+    <img src="/assets/img/extensions-diagram.png" alt="Extensions Diagram" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>Diagram showing how extensions are configured and accessed.</i></div>
+</div>
+
+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](#maintained-extensions)
+
+## Concepts
+
+### Extension Skeleton
+
+An extension is a plain JavaScript object that has an `id` property, and one or
+more [modules](#modules) and/or [lifecycle hooks](#lifecycle-hooks).
+
+```js
+// 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: At
+[runtime](#registering-at-runtime) and at
+[build time](#registering-at-build-time).
+
+You can leverage one or both strategies. Which one(s) you choose depend on your
+application's requirements. Each [module](#modules) defined by the extension
+becomes available to the core application via the `ExtensionManager`.
+
+#### Registering at Runtime
+
+The `@ohif/viewer` uses a [configuration file](../viewer/configuration.md) at
+startup. The schema for that file includes an `Extensions` key that supports an
+array of extensions to register.
+
+```js
+// prettier-ignore
+const config = {
+  extensions: [
+    MyFirstExtension,
+    [
+      MySecondExtension,
+      { /* MySecondExtensions Configuration */ },
+    ],
+  ];
+}
+```
+
+#### Registering at Build Time
+
+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 advantages afforded to us by modern tooling:
+
+- Code Splitting (dynamic imports)
+- 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
+
+Currently, there is only a single lifecycle hook for extensions:
+[`preRegistration`](./lifecycle/pre-registration.md)
+
+If an extension defines the [`preRegistration`](./lifecycle/pre-registration.md)
+lifecycle hook, it is called before any modules are registered in the
+`ExtensionManager`. It's most commonly used to wire up extensions to
+[services](./../services/index.md) and [commands](./modules/commands.md), and to
+bootstrap 3rd party libraries.
+
+### Modules
+
+Modules are the meat of extensions. They provide "definitions", components, and
+filtering/mapping logic that are then made available by various managers and
+services.
+
+Each module type has a special purpose, and is consumed by our viewer
+differently.
+
+| Type                                              | Description                                                      | Examples                                          |
+| ------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------- |
+| [Commands](./modules/commands.md)                 | Adds named commands, scoped to a context, to the CommandsManager | `setToolActive()`, `nextSeries()`                 |
+| [Panel](./modules/panel.md)                       | Adds left or right hand side panels                              | `<ThumbnailList />`, `<MeasurementsTable />`      |
+| [SOPClassHandler](./modules/sop-class-handler.md) | Determines how retrieved study data is split into "DisplaySets"  | `getDisplaySetFromSeries()`                       |
+| [Toolbar](./modules/toolbar.md)                   | Adds buttons or custom components to the toolbar                 | Toolbar button, nested buttons, custom            |
+| [Viewport](./modules/viewport.md)                 | Adds a component responsible for rendering a "DisplaySet"        | `<CornerstoneViewport />`, `<DicomPdfViewport />` |
+
+<figure style="text-align: center; font-style: italic;">Tbl. Module types with abridged descriptions and examples. Each module links to a dedicated documentation page.</figure>
+
+### Contexts
+
+The `@ohif/viewer` tracks "active contexts" that extensions can use to scope
+their functionality. Some example contexts being:
+
+- Route: `ROUTE:VIEWER`, `ROUTE:STUDY_LIST`
+- Active Viewport: `ACTIVE_VIEWPORT:CORNERSTONE`, `ACTIVE_VIEWPORT:VTK`
+
+An extension module can use these to say "Only show this Toolbar Button if the
+active viewport is a Cornerstone viewport." This helps us use the appropriate UI
+and behaviors depending on the current contexts.
+
+For example, if we have hotkey that "rotates the active viewport", each Viewport
+module that supports this behavior can add a command with the same name, scoped
+to the appropriate context. When the `command` is fired, the "active contexts"
+are used to determine the appropriate implementation of the rotate behavior.
+
+## Consuming Extensions
+
+We consume extensions, via the `ExtensionManager`, in our `@ohif/viewer`
+project.
+
+```js
+const extensionManager = new ExtensionManager({
+  commandsManager,
+  servicesManager,
+  hotkeysManager
+});
+
+// prettier-ignore
+extensionManager.registerExtensions([ /** **/ ]);
+```
+
+The `@ohif/viewer` project handles data fetching, basic routing, wires up UI
+services, and is the home to the more bespoke application logic that doesn't
+make as much sense to make reusable.
+
+Long-term, replacing the `@ohif/viewer` application and consuming extensions
+(and the `ExtensionManager`) in your own project is the ideal path for
+applications requiring a high degree of customization that can't be achieved
+with current theming, configuration, extension, and services support.
+
+If you're not sure how to achieve your goals with the extensibility available
+today, create a GitHub issue!
+
+### `ExtensionManager`
+
+The `ExtensionManager` is a class made available to us via the `@ohif/core`
+project (platform/core). Our application instantiates a single instance of it,
+and provides a `ServicesManager` and `CommandsManager` along with the
+application's configuration through the appConfig key (optional).
+
+```js
+const commandsManager = new CommandsManager();
+const servicesManager = new ServicesManager();
+const extensionManager = new ExtensionManager({
+  commandsManager,
+  servicesManager,
+  appConfig,
+});
+```
+
+The `ExtensionManager` only has a few public members:
+
+- `registerExtension` - Registers a single extension
+- `registerExtensions` - Registers an array of extensions
+- `modules` - An object containing registered extensions by `MODULE_TYPE`
+
+During registration, lifecycle hooks and modules have access to the extension's
+config, the application's config and `ExtensionManager`'s `ServicesManager` and
+`CommandsManager` instances.
+
+Our `@ohif/viewer` uses the `modules` member to access registered extensions at
+appropriate places in our application.
+
+## Maintained Extensions
+
+A small number of powerful extensions for popular use cases are maintained by
+OHIF. They're co-located in the [`OHIF/Viewers`][viewers-repo] repository, in
+the top level [`extensions/`][ext-source] directory.
+
+{% include "./_maintained-extensions-table.md" %}
+
+<!--
+  LINKS
+-->
+
+<!-- prettier-ignore-start -->
+[viewers-repo]: https://github.com/OHIF/Viewers
+[ext-source]: https://github.com/OHIF/Viewers/tree/master/extensions
+[module-types]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/extensions/MODULE_TYPES.js
+<!-- prettier-ignore-end -->

docs/v2/extensions/lifecycle/pre-registration.md

@@ -0,0 +1,40 @@
+# Lifecylce Hook: preRegistration
+
+If an extension defines the `preRegistration` lifecycle hook, it is called
+before any modules are registered in the `ExtensionManager`. This hook can be
+used to:
+
+- initialize 3rd party libraries
+- register event listeners
+- add or call services
+- add or call commands
+
+The `preRegistration` hook receives an object containing the
+`ExtensionManager`'s associated `ServicesManager`, `CommandsManager`, and any
+`configuration` that was provided with the extension at time of registration.
+
+_Example `preRegistration` hook implementation_
+
+```js
+export default {
+  id: 'MyExampleExtension',
+
+  /**
+   * @param {object} params
+   * @param {object} params.configuration
+   * @param {ServicesManager} params.servicesManager
+   * @param {CommandsManager} params.commandsManager
+   * @returns void
+   */
+  preRegistration({ servicesManager, commandsManager, configuration }) {
+    console.log('Wiring up important stuff.');
+
+    window.importantStuff = () => {
+      console.log(configuration);
+    };
+
+    console.log('Important stuff has been wired.');
+    window.importantStuff();
+  },
+};
+```

docs/v2/extensions/modules/commands.md

@@ -0,0 +1,158 @@
+# Module: Commands
+
+- [Overview](#overview)
+- [Command Definitions](#command-definitions)
+- [Commands Manager](#commands-manager)
+  - [Instantiating](#instatiating)
+  - [Public API](#public-api)
+  - [Contexts](#contexts)
+
+## Overview
+
+An extension can register a Commands Module by defining a `getCommandsModule`
+method. The Commands Module allows us to register one or more commands scoped to
+specific [contexts](./../index.md#contexts). Commands have several unique
+characteristics that make them tremendously powerful:
+
+- Multiple implementations for the same command can be defined
+- Only the correct command's implementation will be run, dependent on the
+  application's "context"
+- Commands can be called from extensions, modules, and the consuming application
+
+Here is a simple example commands module:
+
+```js
+export default {
+  id: 'example-commands-module',
+
+  /**
+   * @param {object} params
+   * @param {ServicesManager} params.servicesManager
+   * @param {CommandsManager} params.commandsManager
+   */
+  getCommandsModule({ servicesManager, commandsManager }) {
+    return {
+      definitions: {
+        sayHello: {
+          commandFn: ({ words }) => {
+            console.log(words);
+          },
+          options: { words: 'Hello!' },
+        },
+      },
+      defaultContext: 'VIEWER',
+    };
+  },
+};
+```
+
+Each definition returned by the Commands Module is registered to the
+`ExtensionManager`'s `CommandsManager`.
+
+## Command Definitions
+
+The command definition consists of a named command (`myCommandName` below) and a
+`commandFn`. The command name is used to call the command, and the `commandFn`
+is the "command" that is actioned.
+
+```js
+myCommandName: {
+	commandFn: ({ viewports, other, options }) => { },
+	storeContexts: ['viewports'],
+	options: { words: 'Just kidding! Goodbye!' },
+	context: 'ACTIVE_VIEWPORT::CORNERSTONE',
+}
+```
+
+| Property        | Type               | Description                                                                                                                             |
+| --------------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
+| `commandFn`     | func               | The function to call when command is run. Receives `options` and `storeContexts`.                                                       |
+| `storeContexts` | string[]           | (optional) Expected state objects to be passed in as props. Located using `getAppState` fn defined at `CommandsManager`'s instatiation. |
+| `options`       | object             | (optional) Arguments to pass at the time of calling to the `commandFn`                                                                  |
+| `context`       | string[] or string | (optional) Overrides the `defaultContext`. Let's us know if command is currently "available" to be run.                                 |
+
+## Command Behavior
+
+**I have many similar commands. How can I share their `commandFn` and make it
+reusable?**
+
+This is where `storeContexts` and `options` come in. We use these in our
+`setToolActive` command. `storeContexts` helps us identify our `activeViewport`,
+and `options` allow us to pass in the name of a tool we would like to set as
+active.
+
+**If there are multiple valid commands for the application's active contexts**
+
+- What happens: all commands are run
+- When to use: A `clearData` command that cleans up state for multiple
+  extensions
+
+**If no commands are valid for the application's active contexts**
+
+- What happens: a warning is printed to the console
+- When to use: a `hotkey` (like "invert") that doesn't make sense for the
+  current viewport (PDF or HTML)
+
+## `CommandsManager`
+
+The `CommandsManager` is a class defined in the `@ohif/core` project. A single
+instance of it should be defined in the consuming application, and it should be
+used when constructing the `ExtensionManager`.
+
+### Instantiating
+
+When we instantiate the `CommandsManager`, we need to pass it two methods:
+
+- `getAppState` - Should return the application's state when called
+- `getActiveContexts` - Should return the application's active contexts when
+  called
+
+These methods are used internally to help determine which commands are currently
+valid, and how to provide them with any state they may need at the time they are
+called.
+
+```js
+const commandsManager = new CommandsManager({
+  getAppState,
+  getActiveContexts,
+});
+```
+
+### Public API
+
+If you would like to run a command in the consuming app or an extension, you can
+use one of the following methods:
+
+```js
+// Returns all commands for a given context
+commandsManager.getContext('string');
+
+// Attempts to run a command
+commandsManager.runCommand('speak', { command: 'hello' });
+
+// Run command, but override the active contexts
+commandsManager.runCommand('speak', { command: 'hello' }, ['VIEWER']);
+```
+
+The `ExtensionManager` handles registering commands and creating contexts, so
+most consumer's won't need these methods. If you find yourself using these, ask
+yourself "why can't I register these commands via an extension?"
+
+```js
+// Used by the `ExtensionManager` to register new commands
+commandsManager.registerCommand('context', 'name', commandDefinition);
+
+// Creates a new context; clears the context if it already exists
+commandsManager.createContext('string');
+```
+
+### Contexts
+
+It is up to the consuming application to define what contexts are possible, and
+which ones are currently active. As extensions depend heavily on these, we will
+likely publish guidance around creating contexts, and ways to override extension
+defined contexts in the near future. If you would like to discuss potential
+changes to how contexts work, please don't hesistate to createa new GitHub
+issue.
+
+[Some additional information on Contexts can be found here.](./../index.md#contexts)

docs/v2/extensions/modules/panel.md

@@ -0,0 +1,61 @@
+# Module: Panel
+
+An extension can register a Panel Module by defining a `getPanelModule` method.
+The panel module provides the ability to define `menuOptions` and `components`
+that can be used by the consuming application. `components` are React Components
+that can be displayed in the consuming application's "Panel" Component.
+
+![Panel Extension](../../assets/img/extensions-panel.gif)
+
+<center><i>A panel extension example</i></center>
+
+The `menuOptions`'s `target` key points to a registered `components`'s `id`. A
+`defaultContext` is applied to all `menuOption`s; however, each `menuOption` can
+optional provide it's own `context` value.
+
+The `getPanelModule` receives an object containing the `ExtensionManager`'s
+associated `ServicesManager` and `CommandsManager`.
+
+```js
+import MyComponent from './MyComponent.js';
+
+export default {
+  id: 'example-panel-module',
+
+  /**
+   * @param {object} params
+   * @param {ServicesManager} params.servicesManager
+   * @param {CommandsManager} params.commandsManager
+   */
+  getPanelModule({ servicesManager, commandsManager }) {
+    return {
+      menuOptions: [
+        {
+          // A suggested icon
+          // Available icons determined by consuming app
+          icon: 'list',
+          // A suggested label
+          label: 'Magic',
+          // 'right' or 'left'
+          from: 'right',
+          // The target component to toggle open/close
+          target: 'target-component-id',
+          // UI Hint; If the target panel is in a "disabled" state
+          isDisabled: studies => {
+            return false;
+          },
+          // Overrides `defaultContext`, if specified
+          context: ['ACTIVE_VIEWPORT:MAGIC'],
+        },
+      ],
+      components: [
+        {
+          id: 'target-component-id',
+          component: MyComponent,
+        },
+      ],
+      defaultContext: ['ROUTE:VIEWER'],
+    };
+  },
+};
+```

docs/v2/extensions/modules/sop-class-handler.md

@@ -0,0 +1,105 @@
+# Module: SOP Class Handler
+
+An extension can register a [SOP Class][sop-class-link] Handler Module by
+defining a `getSopClassHandlerModule` method. The [SOP Class][sop-class-link]
+Handler is a bit different from the other modules, as it doesn't provide a `1:1`
+schema for UI or provide it's own components. It instead defines:
+
+- `sopClassUIDs`: an array of string SOP Class UIDs that the
+  `getDisplaySetFromSeries` method should be applied to.
+- `getDisplaySetFromSeries`: a method that maps series and study metadata to a
+  display set
+
+A `displaySet` has the following shape:
+
+```js
+return {
+  plugin: 'html',
+  Modality: 'SR',
+  displaySetInstanceUID: 0,
+  wadoRoot: study.getData().wadoRoot,
+  wadoUri: instance.getData().wadouri,
+  SOPInstanceUID: instance.getSOPInstanceUID(),
+  SeriesInstanceUID: series.getSeriesInstanceUID(),
+  StudyInstanceUID: study.getStudyInstanceUID(),
+  authorizationHeaders,
+};
+```
+
+Where the `plugin` key is used to influence the default `ViewportComponent` for
+rendering the `displaySet`. Additional properties are passed to the
+`ViewportComponent` and used by the default `StudyBrowser` to render
+"thumbnails" for each `displaySet`
+
+## Example SOP Class Handler Module
+
+```js
+const SOP_CLASS_UIDS = {
+  BASIC_TEXT_SR: '1.2.840.10008.5.1.4.1.1.88.11',
+  ENHANCED_SR: '1.2.840.10008.5.1.4.1.1.88.22',
+};
+
+export default {
+  id: 'example-sop-class-handler-module',
+
+/**
+ * @param {object} params
+ * @param {ServicesManager} params.servicesManager
+ * @param {CommandsManager} params.commandsManager
+ */
+getSopClassHandlerModule({ servicesManager, commandsManager }) {
+  return {
+    id: 'OHIFDicomHtmlSopClassHandler',
+    sopClassUIDs: Object.values(SOP_CLASS_UIDS),
+
+    /**
+     * @param {object} series -
+     * @param {object} study -
+     * @param {object} dicomWebClient -
+     * @param {object} authorizationHeaders -
+     */
+    getDisplaySetFromSeries(series, study, dicomWebClient, authorizationHeaders) {
+      const instance = series.getFirstInstance();
+
+      return {
+        plugin: 'html',
+        displaySetInstanceUID: 0,
+        wadoRoot: study.getData().wadoRoot,
+        wadoUri: instance.getData().wadouri,
+        SOPInstanceUID: instance.getSOPInstanceUID(),
+        SeriesInstanceUID: series.getSeriesInstanceUID(),
+        StudyInstanceUID: study.getStudyInstanceUID(),
+        authorizationHeaders,
+      };
+    },
+  }
+};
+```
+
+### More examples :
+
+- [Dicom-HTML SOP][dicom-html-sop]
+- [Dicom-PDF SOP][dicom-pdf-sop]
+- [Dicom-Microscopy SOP][dicom-micro-sop]
+- [Dicom-Segmentation SOP][dicom-seg-sop]
+
+## `@ohif/viewer` usage
+
+We use the `sopClassHandlerModule`s in three different places:
+
+- `ViewerLocalFileData.js`
+- `ViewerRetrieveStudyData.js`
+- `StandaloneRouting.js`
+
+Each time, it is used to map study and series data to `displaySets`. It does
+this by working alongside the `StudyMetadataManager` in `@ohif/core`. That
+manager has the method `createDisplaySets` that takes an array of
+`sopClassHandlerModules`.
+
+<!-- prettier-ignore-start -->
+[sop-class-link]: http://dicom.nema.org/dicom/2013/output/chtml/part04/sect_B.5.html
+[dicom-html-sop]: https://github.com/OHIF/Viewers/blob/master/extensions/dicom-html/src/OHIFDicomHtmlSopClassHandler.js#L4-L12
+[dicom-pdf-sop]: https://github.com/OHIF/Viewers/blob/master/extensions/dicom-pdf/src/OHIFDicomPDFSopClassHandler.js#L4-L6
+[dicom-micro-sop]: https://github.com/OHIF/Viewers/blob/master/extensions/dicom-microscopy/src/DicomMicroscopySopClassHandler.js#L5-L7
+[dicom-seg-sop]: https://github.com/OHIF/Viewers/blob/master/extensions/dicom-segmentation/src/OHIFDicomSegSopClassHandler.js#L5-L7
+<!-- prettier-ignore-end -->

docs/v2/extensions/modules/toolbar.md

@@ -0,0 +1,130 @@
+# Module: Toolbar
+
+An extension can register a Toolbar Module by defining a `getToolbarModule`
+method. This module is commonly used to define:
+
+- [Toolbar buttons](#button-definitions)
+- [Nested toolbar menus](#nested-toolbar-menus)
+- [Custom components](#custom-components)
+
+![Toolbar Extension](../../assets/img/extensions-toolbar.gif)
+
+<center><i>Example toolbar button using the Dialog Service to show CINE controls.</i></center>
+
+## Example Toolbar Module
+
+The Toolbar Module should return an array of `definitions` and a
+`defaultContext`. There are currently a few different variations of definitions,
+each one is detailed further down.
+
+```js
+export default {
+  id: 'example-toolbar-module',
+
+  /**
+   * @param {object} params
+   * @param {ServicesManager} params.servicesManager
+   * @param {CommandsManager} params.commandsManager
+   */
+  getToolbarModule({ servicesManager, commandsManager }) {
+    return {
+      definitions: [
+        /* Array of definitions */
+      ],
+      defaultContext: ['ROUTE:VIEWER'],
+    };
+  },
+};
+```
+
+## Button Definitions
+
+The simplest definition has the following properties:
+
+```js
+{
+  id: 'StackScroll',
+  label: 'Stack Scroll',
+  icon: 'bars',
+  type: 'setToolActive',
+  commandName: 'setToolActive',
+  commandOptions: { toolName: 'StackScroll' },
+},
+```
+
+| property         | description                                                       | values                                    |
+| ---------------- | ----------------------------------------------------------------- | ----------------------------------------- |
+| `id`             | Unique string identifier for the definition                       | \*                                        |
+| `label`          | User/display friendly to show in UI                               | \*                                        |
+| `icon`           | A string name for an icon supported by the consuming application. | \*                                        |
+| `type`           | Used to determine the button's component and behavior             | `"setToolActive"`, `"command"`            |
+| `commandName`    | (optional) The command to run when the button is used.            | Any command registed by a `CommandModule` |
+| `commandOptions` | (optional) Options to pass the target `commandName`               | \*                                        |
+| `context`        | (optional) Overrides module's `defaultContext`                    | Array of string context names             |
+
+Where a button with a `type` of `setToolActive` has an "active" styling applied
+when clicked; removing the active styling from all other buttons.
+
+## Nested Toolbar Menus
+
+You can indicate that buttons should be grouped and nested in a submenu by
+including `buttons` property in a definition:
+
+```js
+{
+  id: 'More',
+  label: 'More',
+  icon: 'ellipse-circle',
+  buttons: [
+    {
+      id: 'cstInvert',
+      label: 'Invert',
+      icon: 'circle',
+      type: 'command',
+      commandName: 'invertViewport',
+    },
+  ],
+},
+```
+
+![Toolbar Extension](../../assets/img/extensions-toolbar-nested.gif)
+
+<center><i>Example toolbar button demonstrating nested buttons.</i></center>
+
+## Custom Components
+
+The Toolbar Modules supports rendering custom components in place of the
+application's default. In place of the `type`, `commandName`, and
+`commandOptions` properties, we instead specify a `CustomComponent`.
+
+```js
+{
+  id: 'Custom',
+  label: 'Custom',
+  icon: 'custom-icon',
+  CustomComponent: CustomToolbarComponent,
+}
+
+```
+
+The `CustomComponent` components will receive the following props:
+
+```html
+<CustomComponent
+  parentContext="{parentContext}"
+  toolbarClickCallback="{_handleToolbarButtonClick.bind(this)}"
+  button="{button}"
+  key="{button.id}"
+  activeButtons="{activeButtonsIds}"
+  isActive="{isActive}"
+/>
+```
+
+| Property               | Type     | Description                     |
+| ---------------------- | -------- | ------------------------------- |
+| `activeButtons`        | string[] | list of active buttons          |
+| `button`               | object   | its own definition object       |
+| `key`                  | string   | React key prop                  |
+| `isActive`             | boolean  | If current button is active     |
+| `parentContext`        | ?        | The parent component's context? |
+| `toolbarClickCallback` | func     | Callback method for clicks      |

docs/v2/extensions/modules/viewport.md

@@ -0,0 +1,46 @@
+# Module: Viewport
+
+An extension can register a Viewport Module by defining a `getViewportModule`
+method that returns a React component. Currently, we use viewport components to
+add support for:
+
+- 2D Medical Image Viewing (cornerstone ext.)
+- Structured Reports as HTML (dicom html ext.)
+- Encapsulated PDFs as PDFs (dicom pdf ext.)
+- Whole Slide Microscopy Viewing (whole slide ext.)
+- etc.
+
+The general pattern is, the [`sopClassHandlerModule`](#) helps us determine
+which Viewport Component a set of `sopClassUIDs` should default to. The Viewport
+Component receives props containing a display set it should know how to render.
+
+## Viewport Component Props
+
+Each `ViewportComponent` will receive the following props:
+
+```html
+<viewportComponent
+  viewportData="{viewportData}"
+  viewportIndex="{viewportIndex}"
+  children="{[children]}"
+/>
+```
+
+| Property        | Type            | Description                       |
+| --------------- | --------------- | --------------------------------- |
+| `children`      | React.element[] |                                   |
+| `viewportData`  | object          | `viewportSpecificData` (probably) |
+| `viewportIndex` | number          |                                   |
+
+### `@ohif/viewer`
+
+Viewport components are managed by the `ViewportGrid` Component. Which Viewport
+component is used depends on:
+
+- The Layout Configuration
+- Registered SopClassHandlers
+- The SopClassUID for visible/selected datasets
+
+![Cornerstone Viewport](../../assets/img/extensions-viewport.png)
+
+<center><i>An example of three cornerstone Viewports</i></center>

docs/v2/faq/browser-support.md

@@ -0,0 +1,47 @@
+# Browser Support
+
+The browsers that we support are specified in the `.browserlistrc` file located
+in the `platform/viewer` project. While we leverage the latest language features
+when writing code, we rely on `babel` to _transpile_ our code so that it can run
+in the browsers that we support.
+
+## In Practice
+
+The OHIF Viewer is capable of _running_ on:
+
+- IE 11
+- FireFox
+- Chrome
+- Safari
+- Edge
+
+However, we do not have the resources to adequately test and maintain bug free
+functionality across all of these. In order to push web based medical imaging
+forward, we focus our development efforts on recent version of modern evergreen
+browsers.
+
+Our support of older browsers equates to our willingness to review PRs for bug
+fixes, and target their minimum JS support whenever possible.
+
+### Polyfills
+
+> A polyfill, or polyfiller, is a piece of code (or plugin) that provides the
+> technology that you, the developer, expect the browser to provide natively.
+
+An example of a polyfill is that you expect `Array.prototype.filter` to exist,
+but for some reason, the browser that's being used has not implemented that
+language feature yet. Our earlier transpilation will rectify _syntax_
+discrepencies, but unimplemented features require a "temporary" implementation.
+That's where polyfills step in.
+
+You can utilize a service like [polyfill.io](https://polyfill.io/v3/) to
+auto-detect and apply polyfills as needed, or you can update the PWA build to
+include polyfill's in your bundle by incorporating [core-js][core-js]
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[core-js]: https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md
+<!-- prettier-ignore-end -->

docs/v2/faq/index.md

@@ -0,0 +1,81 @@
+# Frequently Asked Questions
+
+## Index
+
+- [Report a bug][report-bug]
+- [Request a feature][new-feature]
+- [Commercial Support & Consulting][commercial-support]
+- [Academic collaborations][academic]
+- [FDA Clearance or CE Marking][fda-clearance]
+- [HIPAA Compliance][hipaa]
+
+### How do I report a bug?
+
+Navigate to our [GitHub Repository][new-issue], and submit a new bug report.
+Follow the steps outlined in the [Bug Report Template][bug-report-template].
+
+### How can I request a new feature?
+
+At the moment we are in the process of defining our roadmap and will do our best
+to communicate this to the community. If your requested feature is on the
+roadmap, then it will most likely be built at some point. If it is not, you are
+welcome to build it yourself and [contribute it](development/contributing.md).
+If you have resources and would like to fund the development of a feature,
+please [contact us](http://www.ohif.org) or work with community members that
+offer [consulting services][commercial-support].
+
+### Who should I contact about Academic Collaborations?
+
+[Gordon J. Harris](http://www.dfhcc.harvard.edu/insider/member-detail/member/gordon-j-harris-phd/)
+at Massachusetts General Hospital is the primary contact for any academic
+collaborators. We are always happy to hear about new groups interested in using
+the OHIF framework, and may be able to provide development support if the
+proposed collaboration has an impact on cancer research.
+
+### Does OHIF offer commercial support?
+
+The Open Health Imaging Foundation does not offer commercial support, however,
+some community members do offer consulting services. The following contacts may
+be useful:
+
+- Rob Lewis ([Radical Imaging](http://radicalimaging.com/))
+
+**Please file a Pull Request if you wish to add your name or organization to
+this list.**
+
+### Does The OHIF Viewer have [510(k) Clearance][501k-clearance] from the U.S. F.D.A or [CE Marking][ce-marking] from the European Commission?
+
+**NO.** The OHIF Viewer is **NOT** F.D.A. cleared or CE Marked. It is the users
+responsibility to ensure compliance with applicable rules and regulations. The
+[License](https://github.com/OHIF/Viewers/blob/master/LICENSE) for the OHIF
+Platform does not prevent your company or group from seeking F.D.A. clearance
+for a product built using the platform.
+
+If you have gone this route (or are going there), please let us know because we
+would be interested to hear about your experience.
+
+### Is The OHIF Viewer [HIPAA][hipaa-def] Compliant?
+
+**NO.** The OHIF Viewer **DOES NOT** fulfill all of the criteria to become HIPAA
+Compliant. It is the users responsibility to ensure compliance with applicable
+rules and regulations.
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+<!-- INDEX -->
+[report-bug]: #how-do-i-report-a-bug
+[new-feature]: #how-can-i-request-a-new-feature
+[commercial-support]: #does-ohif-offer-commercial-support
+[academic]: #who-should-i-contact-about-academic-collaborations
+[fda-clearance]: #does-the-ohif-viewer-have-510k-clearance-from-the-us-fda-or-ce-marking-from-the-european-commission
+[hipaa]: #is-the-ohif-viewer-hipaa-compliant
+<!-- OTHER -->
+[501k-clearance]: https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/HowtoMarketYourDevice/PremarketSubmissions/PremarketNotification510k/
+[ce-marking]: https://ec.europa.eu/growth/single-market/ce-marking_en
+[hipaa-def]: https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act
+[new-issue]: https://github.com/OHIF/Viewers/issues/new/choose
+[bug-report-template]: https://github.com/OHIF/Viewers/issues/new?assignees=&labels=Bug+Report+%3Abug%3A&template=---bug-report.md&title=
+<!-- prettier-ignore-end -->

docs/v2/faq/pwa-vs-packaged.md

@@ -0,0 +1,56 @@
+# PWA vs Packaged
+
+It's important to know that the OHIF Viewer project provides two different build
+processes:
+
+```bash
+# Static Asset output: For deploying PWAs
+yarn run build
+
+# Single `.js` script, for embedding viewer into existing apps
+yarn run build:package
+```
+
+## Progressive Web Application (PWA)
+
+> [Progressive Web Apps][pwa] are a new breed of web applications that meet the
+> [following requirements][pwa-checklist]. Notably, targeting a PWA allows us
+> provide a reliable, fast, and engaging experience across different devices and
+> network conditions.
+
+The OHIF Viewer is maintained as a [monorepo][monorepo]. We use WebPack to build
+the many small static assets that comprise our application. Also generated is an
+`index.html` that will serve as an entry point for loading configuration and the
+application, as well as a `service-worker` that can intelligently cache files so
+that subsequent requests are from the local file system instead of over the
+network.
+
+You can read more about this particular strategy in our
+[Build for Production Deployment Guide](./../deployment/recipes/build-for-production.md)
+
+## Commonjs Bundle (Packaged Script)
+
+The [@ohif/viewer][viewer-npm] package is built with WebPack to provide a React
+component that can be dropped into a larger application. The `OHIFViewer`
+component is the entire viewer, configurable via React `props`. This is useful
+for including the OHIF Viewer in a larger web application, as the entire
+application can be provided via a `<script>` tag with no build process required.
+
+The bundle is not as performant or as optimized as the PWA build. It includes
+fonts, styles, and the core extensions. If you find yourself facing performance
+issues, you may wish to tweak what's included in this bundle or switch to the
+PWA build.
+
+You can read more about this particular strategy in our
+[Embedded Viewer Deployment Guide](./../deployment/recipes/embedded-viewer.md)
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[pwa]: https://developers.google.com/web/progressive-web-apps/
+[pwa-checklist]: https://developers.google.com/web/progressive-web-apps/checklist
+[monorepo]: https://github.com/OHIF/Viewers/issues/768
+[viewer-npm]: https://www.npmjs.com/package/@ohif/viewer
+<!-- prettier-ignore-end -->

docs/v2/faq/scope-of-project.md

@@ -0,0 +1,66 @@
+# Scope of Project
+
+The OHIF Viewer is a web based medical imaging viewer. This allows it to be used
+on almost any device, anywhere. The OHIF Viewer is what is commonly reffered to
+as a ["Dumb Client"][simplicable]
+
+> A dumb client is software that fully depends on a connection to a server or
+> cloud service for its functionality. Without a network connection, the
+> software offers nothing useful. - [simplicable.com][simplicable]
+
+While the Viewer persists some data, it's scope is limited to caching things
+like user preferences and previous query paramaters. Because of this, the Viewer
+has been built to be highly configurable to work with almost any web accessible
+data source.
+
+![scope-of-project diagram](./../assets/img/scope-of-project.png)
+
+To be more specific, the OHIF Viewer is a collection of HTML, JS, and CSS files.
+These can be delivered to your end users however you would like:
+
+- From the local networok
+- From a remote web server
+- From a CDN (content delivery network)
+- From a service-worker's cache
+- etc.
+
+These "static asset" files are referred to collectively as a "Progressive Web
+Application" (PWA), and have the same capabilities and limitations that all PWAs
+have.
+
+All studies, series, images, imageframes, metadata, and the images themselves
+must come from an external source. There are many, many ways to provide this
+information, the OHIF Viewer's scope **DOES NOT** encompass providing _any_
+data; only the configuration necessary to interface with one or more of these
+many data sources. The OHIF Viewer's scope **DOES** include configuration and
+support for services that are protected with OpenID-Connect.
+
+In an effort to aide our users and contributors, we attempt to provide several
+[deployment and hosting recipes](./deployment/index.md) as potential starting
+points. These are not meant to be rock solid, production ready, solutions; like
+most recipes, they should be augmented to best fit you and your organization's
+taste, preferences, etc.
+
+## FAQ
+
+_Am I able to cache studies for offline viewing?_
+
+Not currently. A web page's offline cache capabilities are limited and somewhat
+volatile (mostly imposed at the browser vendor level). For more robust offline
+caching, you may want to consider a server on the local network, or packaging
+the OHIF Viewer as a desktop application.
+
+_Does the OHIF Viewer work with the local filesystem?_
+
+It is possible to accomplish this through extensions; however, for an user
+experience that accomodates a large number of studies, you would likely need to
+package the OHIF Viewer as an [Electron app][electron].
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[simplicable]: https://simplicable.com/new/dumb-client
+[electron]: https://electronjs.org/
+<!-- prettier-ignore-end -->

docs/v2/help.md

@@ -0,0 +1,39 @@
+# Help
+
+We all need a little help sometimes. Don't let a few roadblocks stand in the way
+of you building something awesome.
+
+## Community Support
+
+If you're a developer looking to contribute code, documentation, or discussion;
+we are more than happy to help provide clarification and answer questions via
+[GitHub issues][gh-issues] or our [community forum][google-group]. Regular
+contributors may also be invited to join our Slack Group to streamline
+discussion.
+
+For bug reports and feature requests (including incomplete or confusing
+documentation), [GitHub issues][gh-issues] continue to be your best avenue of
+communication.
+
+Complex issues specific to your organization/situation are still okay to post,
+but they're less likely to receive a response. Unfortunately, we have limited
+resources and must be judicious with how we allocate them. If you find yourself
+in this situation and in need of assistance, it may be in your best interest to
+persue paid support.
+
+## Commercial Support
+
+The Open Health Imaging Foundation does not offer commercial support, however,
+some community members do offer consulting services:
+
+- Rob Lewis ([Radical Imaging](http://radicalimaging.com/))
+
+**Please file a Pull Request if you wish to add your name or organization to
+this list.**
+
+<!--
+  Links
+  -->
+
+[gh-issues]: https://github.com/OHIF/Viewers/issues/
+[google-group]: https://groups.google.com/forum/#!forum/cornerstone-platform

docs/v2/our-process.md

@@ -0,0 +1,160 @@
+# Our Process
+
+Our process is a living, breathing thing. We strive to have regular
+[retrospectives][retrospective] that help us shape and adapt our process to our
+team's current needs. This document attempts to capture the broad strokes of
+that process in an effort to:
+
+- Strengthen community member involvement and understanding
+- Welcome feedback and helpful suggestions
+
+## Overview
+
+- [Issue Triage](#issue-triage)
+- [Issue Curation ("backlog grooming")](#issue-curation-backlog-grooming)
+- [Contributions (Pull Requests)](#contributions-pull-requests)
+- [Releases](#releases)
+
+_Include issue lifecycle diagram_
+
+## Issue Triage
+
+[GitHub issues][gh-issues] are the best way to provide feedback, ask questions,
+and suggest changes to the OHIF Viewer's core team. Community issues generally
+fall into one of three categories, and are marked with a `triage` label when
+created.
+
+| Issue Template Name    | Description                                                                              |
+| ---------------------- | ---------------------------------------------------------------------------------------- |
+| Community: Report 🐛   | Describe a new issue; Provide steps to reproduce; Expected versus actual result?         |
+| Community: Request ✋  | Describe a proposed new feature. Why should it be implemented? What is the impact/value? |
+| Community: Question ❓ | Seek clarification or assistance relevant to the repository.                             |
+
+_table 1. issue template names and descriptions_
+
+Issues that require `triage` are akin to support tickets. As this is often our
+first contact with would-be adopters and contributors, it's important that we
+strive for timely responses and satisfactory resolutions. We attempt to
+accomplish this by:
+
+1. Responding to issues requiring `triage` at least once a week
+2. Create new "official issues" from "community issues"
+3. Provide clear guidance and next steps (when applicable)
+4. Regularly clean up old (stale) issues
+
+> :pencil: Less obviously, patterns in the issues being reported can highlight
+> areas that need improvement. For example, users often have difficulty
+> navigating CORS issues when deploying the OHIF Viewer -- how do we best reduce
+> our ticket volume for this issue?
+
+### Backlogged Issues
+
+Community issues serve as vehicles of discussion that lead us to "backlogged
+issues". Backlogged issues are the distilled and actionable information
+extracted from community issues. They contain the scope and requirements
+necessary for hand-off to a core-team (or community) contributor ^\_^
+
+| Category | Description                                                                              | Labels                                                                                                                               |
+| -------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| Bugs     | An issue with steps that produce a bug (an unexpected result).                           | [Bug: Verified 🐛][label-bug]                                                                                                        |
+| Stories  | A feature/enhancement with a clear benefit, boundaries, and requirements.                | [Story 🙌][label-story]                                                                                                              |
+| Tasks    | Changes that improve [UX], [DX], or test coverage; but don't impact application behavior | [Task: CI/Tooling 🤖][label-tooling], [Task: Docs 📖][label-docs], [Task: Refactor 🛠][label-refactor], [Task: Tests 🔬][label-tests] |
+
+_table 2. backlogged issue types ([full list of labels][gh-labels])_
+
+## Issue Curation (["backlog grooming"][groom-backlog])
+
+If a [GitHub issue][gh-issues] has a `bug`, `story`, or `task` label; it's on
+our backlog. If an issue is on our backlog, it means we are, at the very least,
+committed to reviewing any community drafted Pull Requests to complete the
+issue. If you're interested in seeing an issue completed but don't know where to
+start, please don't hesitate to leave a comment!
+
+While we don't yet have a long-term or quarterly road map, we do regularly add
+items to our ["Active Development" GitHub Project Board][gh-board]. Items on
+this project board are either in active development by Core Team members, or
+queued up for development as in-progress items are completed.
+
+> 🖋 Want to contribute but not sure where to start? Check out [Up for
+> grabs][label-grabs] issues and our [Contributing
+> documentation][contributing-docs]
+
+## Contributions (Pull Requests)
+
+Incoming Pull Requests (PRs) are triaged using the following labels. Code review
+is performed on all PRs where the bug fix or added functionality is deemed
+appropriate:
+
+| Labels                                         | Description                                                                                                 |
+| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
+| **Classification**                             |                                                                                                             |
+| [PR: Bug Fix][label-bug]                       | Filed to address a Bug.                                                                                     |
+| [PR: Draft][draft]                             | Filed to gather early feedback from the core team, but which is not intended for merging in the short term. |
+| **Review Workflow**                            |                                                                                                             |
+| [PR: Awaiting Response 💬][awaiting-response]  | The core team is waiting for additional information from the author.                                        |
+| [PR: Awaiting Review 👀][awaiting-review]      | The core team has not yet performed a code review.                                                          |
+| [PR: Awaiting Revisions 🖊][awaiting-revisions] | Following code review, this label is applied until the author has made sufficient changes.                  |
+| **QA**                                         |                                                                                                             |
+| [PR: Awaiting User Cases 💃][awaiting-stories] | The PR code changes need common language descriptions of impact to end users before the review can start    |
+| [PR: No UX Impact 🙃][no-ux-impact]            | The PR code changes do not impact the user's experience                                                     |
+
+We rely on GitHub Checks and integrations with third party services to evaluate
+changes in code quality and test coverage. Tests must pass and User cases must
+be present (when applicable) before a PR can be merged to master, and code
+quality and test coverage must not changed by a significant margin. For some
+repositories, visual screenshot-based tests are also included, and video
+recordings of end-to-end tests are stored for later review.
+
+[You can read more about our continous integration efforts here](/development/continous-integration.md)
+
+## Releases
+
+Releases are made automatically based on the type of commits which have been
+merged (major.minor.patch). Releases are automatically pushed to NPM. Release
+notes are automatically generated. Users can subscribe to GitHub and NPM
+releases.
+
+We host development, staging, and production environments for the Progressive
+Web Application version of the OHIF Viewer. [Development][ohif-dev] always
+reflects the latest changes on our master branch. [Staging][ohif-stage] is used
+to regression test a release before a bi-weekly deploy to our [Production
+environment][ohif-prod].
+
+Important announcements are made on GitHub, tagged as Announcement, and pinned
+so that they remain at the top of the Issue page.
+
+The Core team occasionally performs full manual testing to begin the process of
+releasing a Stable version. Once testing is complete, the known issues are
+addressed and a Stable version is released.
+
+<!--
+  LINKS
+-->
+
+<!-- prettier-ignore-start -->
+[groom-backlog]: https://www.agilealliance.org/glossary/backlog-grooming
+[retrospective]: https://www.atlassian.com/team-playbook/plays/retrospective
+[gh-issues]: https://github.com/OHIF/Viewers/issues/new/choose
+[gh-labels]: https://github.com/OHIF/Viewers/labels
+<!-- Issue Labels -->
+[label-story]: https://github.com/OHIF/Viewers/labels/Story%20%3Araised_hands%3A
+[label-tooling]: https://github.com/OHIF/Viewers/labels/Task%3A%20CI%2FTooling%20%3Arobot%3A
+[label-docs]: https://github.com/OHIF/Viewers/labels/Task%3A%20Docs%20%3Abook%3A
+[label-refactor]: https://github.com/OHIF/Viewers/labels/Task%3A%20Refactor%20%3Ahammer_and_wrench%3A
+[label-tests]: https://github.com/OHIF/Viewers/labels/Task%3A%20Tests%20%3Amicroscope%3A
+[label-bug]: https://github.com/OHIF/Viewers/labels/Bug%3A%20Verified%20%3Abug%3A
+<!-- PR Labels -->
+[draft]: https://github.com/OHIF/Viewers/labels/PR%3A%20Draft
+[awaiting-response]: https://github.com/OHIF/Viewers/labels/PR%3A%20Awaiting%20Response%20%3Aspeech_balloon%3A
+[awaiting-review]: https://github.com/OHIF/Viewers/labels/PR%3A%20Awaiting%20Review%20%3Aeyes%3A
+[awaiting-stories]: https://github.com/OHIF/Viewers/labels/PR%3A%20Awaiting%20UX%20Stories%20%3Adancer%3A
+[awaiting-revisions]: https://github.com/OHIF/Viewers/labels/PR%3A%20Awaiting%20Revisions%20%3Apen%3A
+[no-ux-impact]: https://github.com/OHIF/Viewers/labels/PR%3A%20No%20UX%20Impact%20%3Aupside_down_face%3A
+<!-- -->
+[ohif-dev]: https://viewer-dev.ohif.org
+[ohif-stage]: https://viewer-stage.ohif.org
+[ohif-prod]: https://viewer.ohif.org
+[gh-board]: https://github.com/OHIF/Viewers/projects/4
+[label-grabs]: https://github.com/OHIF/Viewers/issues?q=is%3Aissue+is%3Aopen+label%3A%22Up+For+Grabs+%3Araising_hand_woman%3A%22
+[contributing-docs]: ./development/contributing.md
+<!-- prettier-ignore-end -->

docs/v2/package.json

@@ -0,0 +1,44 @@
+{
+  "name": "ohif-viewer-latest-docs",
+  "version": "2.0.0",
+  "description": "Open Health Imaging Foundation Viewers Metarepo for documentation",
+  "main": ".eslintrc.js",
+  "directories": {
+    "doc": "docs"
+  },
+  "scripts": {
+    "docs": "gitbook install && gitbook serve"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/OHIF/Viewers.git"
+  },
+  "keywords": [
+    "dicom",
+    "cornerstone",
+    "OHIF",
+    "zero",
+    "footprint",
+    "medical",
+    "imaging",
+    "viewer"
+  ],
+  "author": "Open Health Imaging Foundation",
+  "license": "MIT",
+  "bugs": {
+    "url": "https://github.com/OHIF/Viewers/issues"
+  },
+  "homepage": "https://github.com/OHIF/Viewers#readme",
+  "dependencies": {
+    "gitbook-plugin-anchors": "^0.7.1",
+    "gitbook-plugin-edit-link": "^2.0.2",
+    "gitbook-plugin-ga": "^2.0.0",
+    "gitbook-plugin-github": "^3.0.0",
+    "gitbook-plugin-sitemap": "^1.2.0",
+    "gitbook-plugin-theme-cornerstone": "^1.1.4",
+    "gitbook-plugin-versions": "^2.1.4"
+  },
+  "devDependencies": {
+    "gitbook-cli": "^2.3.2"
+  }
+}

docs/v2/quick-start.md

@@ -0,0 +1,28 @@
+# Quick Start
+
+This page details how to get an instance of the OHIF Viewer up and running as
+fast as possible. It shows how to grab a pre-built version of the application,
+point it at your data source (PACS), and plop it on a web server.
+
+## Options
+
+### 1. Pre-built PWA
+
+...
+
+### 2. Script-Tag
+
+...
+
+### 3. Docker
+
+...
+
+## Security Concerns
+
+- Secure your data
+
+## Common Issues
+
+- Missing server rewrite rules
+- CORS issues when requesting data from PACS

docs/v2/services/default/index.md

@@ -0,0 +1,65 @@
+# Services (default)
+
+- [Overview](#overview)
+- [Example](#example)
+
+## Overview
+
+Services are a work in progress. As we are still in the progress of creating a
+non-ui maintained service, this usage may change.
+
+<div style="text-align: center;">
+  <a href="/assets/img/services.png">
+    <img src="/assets/img/services.png" alt="UI Services Diagram" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>Diagram showing relationship between React Context and UI Service</i></div>
+</div>
+
+## Example
+
+The simplest service return a new object that has a `name` property, and
+methods/properties that give the service its functionality. The "Factory
+Function" that creates the service is provided with the implementation (this is
+slightly different for UI Services).
+
+```js
+const _speak = () => {
+  console.warn('Speak is not implemented');
+};
+
+/**
+ * Factory function to create `HelloWorldService`
+ *
+ * @param {object} implementation
+ * @param {function} implementation.speak - Speak's implementation
+ * @returns HelloWorldService
+ */
+export default function createHelloWorldService({ speak }) {
+  return {
+    name: 'HelloWorldService',
+    speak: speak || _speak,
+  };
+}
+```
+
+A service, once created, can be registered with the `ServicesManager` to make it
+accessible to extensions. Similarly, the application code can access named
+services from the `ServicesManager`.
+
+```js
+// In the application
+const speak = () => {
+  window.alert('HELLO WORLD');
+};
+const HelloWorldService = createHelloWorldService({ speak });
+const servicesManager = new ServicesManager();
+
+servicesManager.registerService(HelloWorldService);
+
+// In an extension
+const { HelloWorldService } = servicesManager.services;
+
+if (HelloWorldService) {
+  HelloWorldService.speak();
+}
+```

docs/v2/services/default/measurements.md

@@ -0,0 +1,15 @@
+# Service: Measurements
+
+...
+
+## Usage
+
+## How to define a Measurement tool
+
+## How to validate Measurements
+
+## Data exchange concepts
+
+## Longitudinal Measurements
+
+## Timepoints

docs/v2/services/index.md

@@ -0,0 +1,69 @@
+# Services Overview
+
+- [Overview](#overview)
+- [Kinds of Services](#kinds-of-services)
+  - [Services (default)](#services-default)
+  - [UI Services](#ui-services)
+- [Related Patterns](#related-patterns)
+
+## Overview
+
+Services are a beefier version of [commands][commands]. They provide a set of
+operations, often tied to some shared state, and are made available to
+extensions via the `ServicesManager`. Services are particularly well suited to
+address [cross-cutting concerns][cross-cutting-concerns].
+
+Each service should be:
+
+- self-contained
+- able to fail and/or be removed without breaking the application
+- completely interchangeable with another module implementing the same interface
+
+## Kinds of Services
+
+Depending on the kind of service, we follow slightly different conventions. For
+example, a UI service often receives its implementation from a React Context
+Provider. You can read more about the different kinds of services and what makes
+them different below:
+
+### Services (default)
+
+Services are a work in progress. As we are still in the progress of creating a
+non-ui maintained service, this usage may change.
+
+[You can read more about default services: here](./default/index.md)
+
+### UI Services
+
+A typical web application will have components and state for common UI like
+modals, notifications, dialogs, etc. A UI service makes it possible to leverage
+these components from an extension.
+
+We maintain the following UI Services:
+
+- [UIDialogService](./ui/ui-dialog-service.md)
+- [UIModalService](./ui/ui-modal-service.md)
+- [UINotificationService](./ui/ui-notification-service.md)
+
+You can read more about a specific service by selecting it in the above list,
+and more about [UI services in general: here](./ui/index.md)
+
+## Related Patterns
+
+Services are "concern-specific" code modules that can be consumed across layers.
+We try to minimize the coupling they introduce by authoring services that are
+able to fail or be removed. Related patterns that may reduce coupling include:
+
+- Pub/Sub
+- Commands
+
+<!--
+  LINKS
+  -->
+
+<!-- prettier-ignore-start -->
+[commands]: ../extensions/modules/commands.md
+[core-services]: https://github.com/OHIF/Viewers/tree/master/platform/core/src/services
+[services-manager]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/services/ServicesManager.js
+[cross-cutting-concerns]: https://en.wikipedia.org/wiki/Cross-cutting_concern
+<!-- prettier-ignore-end -->

docs/v2/services/ui/index.md

@@ -0,0 +1,106 @@
+# UI Services
+
+- [Overview](#overview)
+- [Example](#example)
+- [Tips & Tricks](#tips--tricks)
+- [Maintained Services](#maintained-services)
+
+## Overview
+
+A typical web application will have components and state for common UI like
+modals, notifications, dialogs, etc. A UI service makes it possible to leverage
+these components from an extension.
+
+<div style="text-align: center;">
+  <a href="/assets/img/ui-services.png">
+    <img src="/assets/img/ui-services.png" alt="UI Services Diagram" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>Diagram showing relationship between React Context and UI Service</i></div>
+</div>
+
+In `@ohif/core`, we have a collection of service factories. We select one we
+would like our application to support, create an instance of it, and pass that
+instance to our `ServicesManager` AND to a React component (in this example,
+`ModalContext`'s provider).
+
+The `ModalContext`'s provider:
+
+- Exposes context values
+- Exposes methods that leverage `useCallback` hooks
+- Sets the service's implementation in a `useEffect` hook
+
+The `ServicesManager` is:
+
+- Passed to the `ExtensionManager`
+- The `ExtensionManager` makes the `ServicesManager` available to:
+  - All of it's lifecycle hooks (`preRegistration`)
+  - Each "getModuleFunction" (`getToolbarModule`, `getPanelModule`, etc.)
+
+## Example
+
+That's all fine and good, but it's still a little too abstract. What does this
+translate to in practice?
+
+```js
+// In the application
+import UINotificationService from '@ohif/core';
+const servicesManager = new ServicesManager();
+
+servicesManager.registerService(UINotificationService);
+
+// UI Service Provider
+useEffect(() => {
+  if (service) {
+    service.setServiceImplementation({ hide, show });
+  }
+}, [service, hide, show]);
+
+// In an extension
+const { UINotificationService } = servicesManager.services;
+
+if (UINotificationService) {
+  UINotificationService.show('Hello from the other side 👋');
+}
+```
+
+<div style="text-align: center;">
+  <a href="/assets/img/notification-example.gif">
+    <img src="/assets/img/notification-example.gif" alt="UI Notification Service Example" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>GIF showing successful call of UINotificationService from an extension.</i></div>
+</div>
+
+## Tips & Tricks
+
+It's important to remember that all we're doing is making it possible to control
+bits of the application's UI from an extension. Here are a few non-obvious
+takeaways worth mentioning:
+
+- Your application code should continue to use React context
+  (consumers/providers) as it normally would
+- You can substitute our "out of the box" UI implementations with your own
+- You can create and register your own UI services
+- You can choose not to register a service or provide a service implementation
+- In extensions, you can provide fallback/alternative behavior if an expected
+  service is not registered
+  - No `UIModalService`? Use the `UINotificationService` to notify users.
+- While we don't have an examples of this, you can technically register a
+  service in an extension and expose it to the core application
+
+> Note: These are recommended patterns, not hard and fast rules. Following them
+> will help reduce confusion and interoperability with the larger OHIF
+> community, but they're not silver bullets. Please speak up, create an issue,
+> if you would like to discuss new services or improvements to this pattern.
+
+## Maintained Services
+
+Our `@ohif/viewer` project is an example of how to glue together the different
+parts and pieces of the OHIF Platform to create a polished and powerful product.
+To accomplish that, we maintain several UI Services that you can use in your own
+project, or provide alternative implementations for:
+
+| Name                  | Docs                                 |
+| --------------------- | ------------------------------------ |
+| UIDialogService       | [Here](./ui-dialog-service.md)       |
+| UIModalService        | [Here](./ui-modal-service.md)        |
+| UINotificationService | [Here](./ui-notification-service.md) |

docs/v2/services/ui/ui-dialog-service.md

@@ -0,0 +1,49 @@
+# UI Dialog Service
+
+Dialogs have similar characteristics to that of Modals, but often with a
+streamlined focus. They can be helpful when:
+
+- We need to grab the user's attention
+- We need user input
+- We need to show additional information
+
+If you're curious about the DOs and DON'Ts of dialogs and modals, check out this
+article: ["Best Practices for Modals / Overlays / Dialog Windows"][ux-article]
+
+<div style="text-align: center;">
+  <a href="/assets/img/dialog-example.gif">
+    <img src="/assets/img/dialog-example.gif" alt="UI Dialog Service Example" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>GIF showing successful call of UIDialogService from an extension.</i></div>
+</div>
+
+## Interface
+
+For a more detailed look on the options and return values each of these methods
+is expected to support, [check out it's interface in `@ohif/core`][interface]
+
+| API Member     | Description                                            |
+| -------------- | ------------------------------------------------------ |
+| `create()`     | Creates a new Dialog that is displayed until dismissed |
+| `dismiss()`    | Dismisses the specified dialog                         |
+| `dismissAll()` | Dismisses all dialogs                                  |
+
+## Implementations
+
+| Implementation                       | Consumer                   |
+| ------------------------------------ | -------------------------- |
+| [Dialog Provider][dialog-provider]\* | Baked into Dialog Provider |
+
+`*` - Denotes maintained by OHIF
+
+> 3rd Party implementers may be added to this table via pull requests.
+
+<!--
+  LINKS
+-->
+
+<!-- prettier-ignore-start -->
+[interface]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/services/UIDialogService/index.js
+[dialog-provider]: https://github.com/OHIF/Viewers/blob/master/platform/ui/src/contextProviders/DialogProvider.js
+[ux-article]: https://uxplanet.org/best-practices-for-modals-overlays-dialog-windows-c00c66cddd8c
+<!-- prettier-ignore-end -->

docs/v2/services/ui/ui-modal-service.md

@@ -0,0 +1,50 @@
+# UI Modal Service
+
+Modals have similar characteristics to that of Dialogs, but are often larger,
+and only allow for a single instance to be viewable at once. They also tend to
+be centered, and not draggable. They're commonly used when:
+
+- We need to grab the user's attention
+- We need user input
+- We need to show additional information
+
+If you're curious about the DOs and DON'Ts of dialogs and modals, check out this
+article: ["Best Practices for Modals / Overlays / Dialog Windows"][ux-article]
+
+<div style="text-align: center;">
+  <a href="/assets/img/modal-example.gif">
+    <img src="/assets/img/modal-example.gif" alt="UI Modal Service Example" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>GIF showing successful call of UIModalService from an extension.</i></div>
+</div>
+
+## Interface
+
+For a more detailed look on the options and return values each of these methods
+is expected to support, [check out it's interface in `@ohif/core`][interface]
+
+| API Member | Description                           |
+| ---------- | ------------------------------------- |
+| `hide()`   | Hides the open modal                  |
+| `show()`   | Shows the provided content in a modal |
+
+## Implementations
+
+| Implementation                     | Consumer                      |
+| ---------------------------------- | ----------------------------- |
+| [Modal Provider][modal-provider]\* | [OHIFModal][modal-consumer]\* |
+
+`*` - Denotes maintained by OHIF
+
+> 3rd Party implementers may be added to this table via pull requests.
+
+<!--
+  LINKS
+-->
+
+<!-- prettier-ignore-start -->
+[interface]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/services/UIModalService/index.js
+[modal-provider]: https://github.com/OHIF/Viewers/blob/master/platform/ui/src/contextProviders/ModalProvider.js
+[modal-consumer]: https://github.com/OHIF/Viewers/tree/master/platform/ui/src/components/ohifModal
+[ux-article]: https://uxplanet.org/best-practices-for-modals-overlays-dialog-windows-c00c66cddd8c
+<!-- prettier-ignore-end -->

docs/v2/services/ui/ui-notification-service.md

@@ -0,0 +1,51 @@
+# UI Notification Service
+
+Notifications can be annoying and disruptive. They can also deliver timely
+helpful information, or expedite the user's workflow. Here is some high level
+guidance on when and how to use them:
+
+- Notifications should be non-interfering (timely, relevant, important)
+- We should only show small/brief notifications
+- Notifications should be contextual to current behavior/actions
+- Notifications can serve warnings (acting as a confirmation)
+
+If you're curious about the DOs and DON'Ts of notifications, check out this
+article: ["How To Design Notifications For Better UX"][ux-article]
+
+<div style="text-align: center;">
+  <a href="/assets/img/notification-example.gif">
+    <img src="/assets/img/notification-example.gif" alt="UI Notification Service Example" style="margin: 0 auto; max-width: 500px;" />
+  </a>
+  <div><i>GIF showing successful call of UINotificationService from an extension.</i></div>
+</div>
+
+## Interface
+
+For a more detailed look on the options and return values each of these methods
+is expected to support, [check out it's interface in `@ohif/core`][interface]
+
+| API Member | Description                             |
+| ---------- | --------------------------------------- |
+| `hide()`   | Hides the specified notification        |
+| `show()`   | Creates and displays a new notification |
+
+## Implementations
+
+| Implementation                           | Consumer                                  |
+| ---------------------------------------- | ----------------------------------------- |
+| [Snackbar Provider][snackbar-provider]\* | [SnackbarContainer][snackbar-container]\* |
+
+`*` - Denotes maintained by OHIF
+
+> 3rd Party implementers may be added to this table via pull requests.
+
+<!--
+  LINKS
+-->
+
+<!-- prettier-ignore-start -->
+[interface]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/services/UINotificationService/index.js
+[snackbar-provider]: https://github.com/OHIF/Viewers/blob/master/platform/ui/src/contextProviders/SnackbarProvider.js
+[snackbar-container]: https://github.com/OHIF/Viewers/blob/master/platform/ui/src/components/snackbar/SnackbarContainer.js
+[ux-article]: https://uxplanet.org/how-to-design-notifications-for-better-ux-6fb0711be54d
+<!-- prettier-ignore-end -->

docs/v2/viewer/configuration.md

@@ -0,0 +1,119 @@
+# Viewer: Configuration
+
+We maintain a number of common viewer application configurations at
+[`<root>/platform/viewer/public/configs`][config-dir]. How these values are
+passed to the viewer depend on how it's deployed, but the two most common paths
+are:
+
+- `index.html` looks for `https://your-website.com/app-config.js` OR
+- `index.html` passes the values to `OHIF.installViewer()`
+
+```js
+window.config = {
+  routerBasename: '/',
+  /**
+   * "White Labeling" is used to change the branding, look, and feel of the OHIF
+   * Viewer. These settings, and the color variables that are used by our components,
+   * are the easiest way to rebrand the application.
+   *
+   * More extensive changes are made possible through swapping out the UI library,
+   * Viewer project, or extensions.
+   */
+  whiteLabeling: {
+    /* Optional: Should return a React component to be rendered in the "Logo" section of the application's Top Navigation bar */
+    createLogoComponentFn: function(React) {
+      return React.createElement('a', {
+        target: '_self',
+        rel: 'noopener noreferrer',
+        className: 'header-brand',
+        href: '/',
+        style: {
+          display: 'block',
+          textIndent: '-9999px',
+          background: 'url(/svg-file-hosted-at-domain-root.svg)',
+          backgroundSize: 'contain',
+          backgroundRepeat: 'no-repeat',
+          width: '200px',
+        },
+      });
+    },
+  },
+  /**
+   * Internally, the OHIF Viewer fetches data primarily with the
+   * `cornerstoneWADOImageLoader` and the `DICOMWebClient`. If either of these
+   * receive a non-200 response, this method allows you to handle that error.
+   *
+   * Common use cases include:
+   * - Showing a notification with the UINotificationService
+   * - Redirecting the user
+   * - Refreshing an auth token
+   *
+   * @param {Object} error - JS new Error()
+   * @param {XMLHttpRequest} error.request - The XHR request that's onreadystate change triggered this callback
+   * @param {string} error.response - The XHR's response property
+   * @param {number} error.status - The XHR's status property
+   */
+  httpErrorHandler: error => {
+    const { request: xhr, response, status } = err;
+    const { responseType, statusText } = xhr;
+
+    // In local files, status is 0 upon success in Firefox
+    if (xhr.readyState === XMLHttpRequest.DONE) {
+      console.log(statusText, response, responseType);
+    } else {
+      console.warn('Likely CORS error');
+    }
+  },
+  extensions: [],
+  showStudyList: true,
+  filterQueryParam: false,
+  servers: {
+    dicomWeb: [
+      {
+        name: 'DCM4CHEE',
+        wadoUriRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado',
+        qidoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
+        wadoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
+        qidoSupportsIncludeField: true,
+        imageRendering: 'wadors',
+        thumbnailRendering: 'wadors',
+        enableStudyLazyLoad: true,
+      },
+    ],
+  },
+  // Supported Keys: https://craig.is/killing/mice
+  hotkeys: [
+    { commandName: 'rotateViewportCW', label: 'Rotate Right', keys: ['r'] },
+    { commandName: 'rotateViewportCCW', label: 'Rotate Left', keys: ['l'] },
+    { commandName: 'invertViewport', label: 'Invert', keys: ['i'] },
+    {
+      commandName: 'flipViewportVertical',
+      label: 'Flip Horizontally',
+      keys: ['h'],
+    },
+    {
+      commandName: 'flipViewportHorizontal',
+      label: 'Flip Vertically',
+      keys: ['v'],
+    },
+  ],
+  /* Configuration passed to the bundled cornerstone extension
+   *
+   * The cornerstone extension is currently tightly coupled to the platform.
+   * Until we're able to decouple it, this key will serve as a workaround to
+   * pass it configuration.
+   */
+  cornerstoneExtensionConfig: {
+    /* Whether to show/hide annotation "handles" */
+    hideHandles: true,
+  },
+};
+```
+
+<!--
+  LINKS
+-->
+
+<!-- prettier-ignore-start -->
+[config-dir]: https://github.com/OHIF/Viewers/tree/master/platform/viewer/public/config
+<!-- prettier-ignore-end -->

docs/v2/viewer/environment-variables.md

@@ -0,0 +1,23 @@
+# Environment Variables
+
+There are a number of environment variables we use at build time to influence the output application's behavior.
+
+```bash
+# Application
+NODE_ENV=< production | development >
+DEBUG=< true | false >
+APP_CONFIG=< relative path to application configuration file >
+PUBLIC_URL=<>
+VERSION_NUMBER=<Set by CircleCI>
+BUILD_NUM=<Set by CircleCI>
+# i18n
+USE_LOCIZE=<false>
+LOCIZE_PROJECTID=<ProjectID to pull translations for>
+LOCIZE_API_KEY=<To enable Locize live editing of translations>
+```
+
+## Setting Environment Variables
+
+- `npx cross-env`
+- `.env` files
+- env variables on build machine, or for terminal session

docs/v2/viewer/hotkeys.md

@@ -0,0 +1,3 @@
+# Hotkeys
+
+...

docs/v2/viewer/index.md

@@ -0,0 +1,9 @@
+# Viewer
+
+The OHIF Viewing Platform strives to be highly configurable and extensible. This
+makes it easier for our community members to keep their "secret sauce" private,
+and incentivises contributions back to the platform. The `@ohif/viewer` project
+of the platform is the lynchpin that combines everything to create our
+application.
+
+- When configuration and themeing aren't enough

docs/v2/viewer/internationalization.md

@@ -0,0 +1,317 @@
+# Viewer: Internationalization
+
+OHIF supports internationalization using [i18next](https://www.i18next.com/)
+through the npm package [@ohif/i18n](https://www.npmjs.com/package/@ohif/i18n),
+where is the main instance of i18n containing several languages and tools.
+
+<div class='row'>
+  <div class='column'>
+    <p>Our translation management is powered by <a href="https://locize.com/" target="_blank" rel="noopener noreferrer">Locize</a> through their generous support of open source.</p>
+  </div>
+  <div class='column'>
+    <a href="https://locize.com/" target="_blank" rel="noopener noreferrer" style='padding: 20px'>
+      <img src="../assets/img/locizeSponsor.svg" alt="Locize Translation Management Logo">
+    </a>
+  </div>
+</div>
+
+## Installing
+
+```bash
+yarn add @ohif/i18n
+
+# OR
+
+npm install --save @ohif/i18n
+```
+
+## How it works
+
+After installing `@ohif/i18n` npm package, the translation function
+[t](https://www.i18next.com/overview/api#t) can be used [with](#with-react) or
+[without](#without-react) React.
+
+A translation will occur every time a text match happens in a
+[t](https://www.i18next.com/overview/api#t) function.
+
+The [t](https://www.i18next.com/overview/api#t) function is responsible for
+getting translations using all the power of i18next.
+
+E.g.
+
+Before:
+
+```html
+<div>my translated text</div>
+```
+
+After:
+
+```html
+<div>{t('my translated text')}</div>
+```
+
+If the translation.json file contains a key that matches the HTML content e.g.
+`my translated text`, it will be replaced automatically by the
+[t](https://www.i18next.com/overview/api#t) function.
+
+---
+
+### With React
+
+This section will introduce you to [react-i18next](https://react.i18next.com/)
+basics and show how to implement the [t](https://www.i18next.com/overview/api#t)
+function easily.
+
+#### Using HOCs
+
+In most cases we used
+[High Order Components](https://react.i18next.com/latest/withtranslation-hoc) to
+share the `t` function among OHIF's components.
+
+E.g.
+
+```js
+import React from 'react';
+import { withTranslation } from '@ohif/i18n';
+
+function MyComponent({ t, i18n }) {
+  return <p>{t('my translated text')}</p>;
+}
+
+export default withTranslation('MyNameSpace')(MyComponent);
+```
+
+> Important: if you are using React outside the OHIF Viewer, check the
+> [I18nextProvider](#using-outside-of-ohif-viewer) section, `withTranslation`
+> HOC doesnt works without a I18nextProvider
+
+#### Using Hooks
+
+Also, it's possible to get the `t` tool using
+[React Hooks](https://react.i18next.com/latest/usetranslation-hook), but it
+requires at least React > 16.8 😉
+
+### Using outside of OHIF viewer
+
+OHIF Viewer already sets a main
+[I18nextProvider](https://react.i18next.com/latest/i18nextprovider) connected to
+the shared i18n instance from `@ohif/i18n`, all extensions inside OHIF Viewer
+will share this same provider at the end, you don't need to set new providers at
+all.
+
+But, if you need to use it completely outside of OHIF viewer, you can set the
+I18nextProvider this way:
+
+```js
+import i18n from '@ohif/i18n';
+import { I18nextProvider } from 'react-i18next';
+import App from './App';
+
+<I18nextProvider i18n={i18n}>
+  <App />
+</I18nextProvider>;
+```
+
+After setting `I18nextProvider` in your React App, all translations from
+`@ohif/i18n` should be available following the basic [With React](#with-react)
+usage.
+
+---
+
+### Without React
+
+When needed, you can also use available translations _without React_.
+
+E.g.
+
+```js
+import { T } from '@ohif/i18n';
+console.log(T('my translated text'));
+console.log(T('$t(Common:Play) my translated text'));
+```
+
+---
+
+# Main Concepts While Translating
+
+## Namespaces
+
+Namespaces are being used to organize translations in smaller portions, combined
+semantically or by use. Each `.json` file inside `@ohif/i18n` npm package
+becomes a new namespace automatically.
+
+- Buttons: All buttons translations
+- CineDialog: Translations for the toll tips inside the Cine Player Dialog
+- Common: all common jargons that can be reused like `t('$t(common:image)')`
+- Header: translations related to OHIF's Header Top Bar
+- MeasurementTable - Translations for the `@ohif/ui` Measurement Table
+- UserPreferencesModal - Translations for the `@ohif/ui` Preferences Modal
+
+### How to use another NameSpace inside the current NameSpace?
+
+i18next provides a parsing feature able to get translations strings from any
+NameSpace, like this following example getting data from `Common` NameSpace:
+
+```
+$t(Common:Reset)
+```
+
+## Extending Languages in @ohif/i18n
+
+Sometimes, even using the same language, some nouns or jargons can change
+according to the country, states or even from Hospital to Hospital.
+
+In this cases, you don't need to set an entire language again, you can extend
+languages creating a new folder inside a pre existent language folder and
+@ohif/i18n will do the hard work.
+
+This new folder must to be called with a double character name, like the `UK` in
+the following file tree:
+
+```bash
+ |-- src
+    |-- locales
+    index.js
+        |-- en
+            |-- Buttons.json
+            index.js
+            | UK
+               |-- Buttons.js
+               indes.js
+            | US
+               |-- Buttons.js
+               index.js
+  ...
+```
+
+All properties inside a Namespace will be merged in the new sub language, e.g
+`en-US` and `en-UK` will merge the props with `en`, using i18next's fallback
+languages tool.
+
+You will need to export all Json files in your `index.js` file, mounting an
+object like this:
+
+```js
+   {
+     en: {
+       NameSpace: {
+         keyWord1: 'keyWord1Translation',
+         keyWord2: 'keyWord2Translation',
+         keyWord3: 'keyWord3Translation',
+       }
+     },
+     'en-UK': {
+       NameSpace: {
+         keyWord1: 'keyWord1DifferentTranslation',
+       }
+     }
+   }
+```
+
+Please check the `index.js` files inside locales folder for an example of this
+exporting structure.
+
+### Extending languages dynamically
+
+You have access to the i18next instance, so you can use the
+[addResourceBundle](https://www.i18next.com/how-to/add-or-load-translations#add-after-init)
+method to add and change language resources as needed.
+
+E.g.
+
+```js
+import { i18n } from '@ohif/i18n';
+i18next.addResourceBundle('pt-BR', 'Buttons', {
+  Angle: 'Ângulo',
+});
+```
+
+---
+
+### How to set a whole new language
+
+To set a brand new language you can do it in two different ways:
+
+- Opening a pull request for `@ohif/i18n` and sharing the translation with the
+  community. 😍 Please see [Contributing](#contributing-with-new-languages)
+  section for further information.
+
+- Setting it only in your project or extension:
+
+You'll need a a final object like the following, what is setting French as
+language, and send it to `addLocales` method.
+
+```js
+const newLanguage =
+   {
+     fr: {
+       Commons: {
+          "Reset": "Réinitialiser",
+          "Previous": "Précédent",
+       },
+       Buttons: {
+         "Rectangle": "Rectangle",
+         "Circle": "Cercle",
+       }
+     }
+```
+
+To make it easier to translate, you can copy the .json files in the /locales
+folder and theirs index.js exporters, keeping same keys and NameSpaces.
+Importing the main index.js file, will provide you an Object as expected by the
+method `addlocales`;
+
+E.g. of `addLocales` usage
+
+```js
+import { addLocales } from '@ohif/i18n';
+import locales from './locales/index.js';
+addLocales(locales);
+```
+
+You can also set them manually, one by one, using this
+[method](#extending-languages-dynamically).
+
+---
+
+## Language Detections
+
+@ohif/i18n uses
+[i18next-browser-languageDetector](https://github.com/i18next/i18next-browser-languageDetector)
+to manage detections, also exports a method called initI18n that accepts a new
+detector config as parameter.
+
+### Changing the language
+
+OHIF Viewer accepts a query param called `lng` in the url to change the
+language.
+
+E.g.
+
+```
+https://docs.ohif.org/demo/?lng=es-MX
+```
+
+### Language Persistence
+
+The user's language preference is kept automatically by the detector and stored
+at a cookie called 'i18next', and in a localstorage key called 'i18nextLng'.
+These names can be changed with a new
+[Detector Config](https://github.com/i18next/i18next-browser-languageDetector).
+
+## Debugging translations
+
+There is an environment variable responsible for debugging the translations,
+called `REACT_APP_I18N_DEBUG`.
+
+Run the project as following to get full debug information:
+
+```bash
+REACT_APP_I18N_DEBUG=true yarn run dev
+```
+
+### Contributing with new languages
+
+Contributions of any kind are welcome! Please check the
+[instructions](../development/contributing.md).

docs/v2/viewer/themeing.md

@@ -0,0 +1,97 @@
+# Viewer: Themeing
+
+Themeing is currently accomplished with color variables that are defined within
+the [`:root`](https://css-tricks.com/almanac/selectors/r/root/) selector
+(allowing them to cascade across all elements). This repository's components,
+and the ones we consume from our
+[`@ohif/ui` component library](https://react.ohif.org/styling-and-theming)
+utilize them. We are interested in pursuing more robust themeing options, and
+open to pull requests and discussion issues.
+
+```css
+:root {
+  /* Interface UI Colors */
+  --default-color: #9ccef9;
+  --hover-color: #ffffff;
+  --active-color: #20a5d6;
+  --ui-border-color: #44626f;
+  --ui-border-color-dark: #3c5d80;
+  --ui-border-color-active: #00a4d9;
+  --primary-background-color: #000000;
+  --box-background-color: #3e5975;
+
+  --text-primary-color: #ffffff;
+  --text-secondary-color: #91b9cd;
+  --input-background-color: #2c363f;
+  --input-placeholder-color: #d3d3d3;
+
+  --table-hover-color: #2c363f;
+  --table-text-primary-color: #ffffff;
+  --table-text-secondary-color: #91b9cd;
+
+  --large-numbers-color: #6fbde2;
+
+  --state-error: #ffcccc;
+  --state-error-border: #ffcccc;
+  --state-error-text: #ffcccc;
+
+  /* Common palette */
+  --ui-yellow: #e29e4a;
+  --ui-sky-blue: #6fbde2;
+
+  /* State palette */
+  --ui-state-error: #ffcccc;
+  --ui-state-error-border: #993333;
+  --ui-state-error-text: #661111;
+  --ui-gray-lighter: #436270;
+  --ui-gray-light: #516873;
+  --ui-gray: #263340;
+  --ui-gray-dark: #16202b;
+  --ui-gray-darker: #151a1f;
+  --ui-gray-darkest: #14202a;
+
+  --calendar-day-color: #d3d3d3;
+  --calendar-day-border-color: #d3d3d3;
+  --calendar-day-active-hover-background-color: #516873;
+  --calendar-main-color: #263340;
+  --viewport-border-thickness: 1px;
+}
+```
+
+## White Labeling
+
+> A white-label product is a product or service produced by one company (the
+> producer) that other companies (the marketers) rebrand to make it appear as if
+> they had made it - [Wikipedia: White-Label Product][wikipedia]
+
+Current white-labeling options are limited. We expose the ability to replace the
+"Logo" section of the application with a custom "Logo" component. You can do
+this by adding a `whiteLabeling` key to your
+[configuration file](./configuration.md).
+
+```js
+function RadicalImagingLogo(React) {
+  return React.createElement(
+    'a',
+    {
+      target: '_blank',
+      rel: 'noopener noreferrer',
+      className: 'header-brand',
+      href: 'http://radicalimaging.com',
+    },
+    React.createElement('h5', {}, 'RADICAL IMAGING')
+  );
+}
+
+props.whiteLabeling = {
+  createLogoComponentFn: RadicalImagingLogo,
+};
+```
+
+<!--
+  Links
+  -->
+
+<!-- prettier-ignore-start -->
+[wikipedia]: https://en.wikipedia.org/wiki/White-label_product
+<!-- prettier-ignore-end -->