fix/migration 3p11 (#5370)
This commit is contained in:
Alireza authored and GitHub committed
1 parent
df0593aac9
commit
6a1838bf0d
391 files changed
+2322
-215
No files matched your search
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Commands
|
||||
summary: Migration guide for commands in OHIF 3.10, covering the replacement of deleteMeasurement with removeMeasurement and setSourceViewportForReferenceLinesTool with the more generic setViewportForToolConfiguration command.
|
||||
---
|
||||
|
||||
|
||||
# Commands
|
||||
|
||||
## Measurements
|
||||
|
||||
* The `deleteMeasurement` command has been completely removed from the codebase It has been replaced by `removeMeasurement` command with enhanced functionality
|
||||
|
||||
1. Replace any usage of `deleteMeasurement` with `removeMeasurement` in your custom code
|
||||
|
||||
```diff
|
||||
- commandsManager.run('deleteMeasurement', { uid });
|
||||
+ commandsManager.run('removeMeasurement', { uid });
|
||||
```
|
||||
|
||||
|
||||
## Important Notes:
|
||||
|
||||
* This change is part of a broader refactoring of the measurement system to provide more consistent and powerful APIs
|
||||
* The new command structure follows a more consistent pattern throughout the codebase
|
||||
* If you were using `measurementServiceSource.remove(uid)` directly, you should now use `measurementService.remove(uid)` instead
|
||||
* The changes affect both UI components and any extensions that integrate with the measurement system
|
||||
* Removal functionality now works with both individual UIDs and arrays of UIDs for batch operations
|
||||
|
||||
|
||||
|
||||
## `setSourceViewportForReferenceLinesTool`
|
||||
|
||||
* `setSourceViewportForReferenceLinesTool` has been replaced by the more generic `setViewportForToolConfiguration`
|
||||
* The new API allows configuration of any tool, not just the ReferenceLinesTool
|
||||
* Tool name is now a required parameter, not hardcoded to ReferenceLinesTool
|
||||
|
||||
## Migration Steps:
|
||||
|
||||
1. Update command references from `setSourceViewportForReferenceLinesTool` to `setViewportForToolConfiguration`
|
||||
|
||||
```diff
|
||||
- {
|
||||
- commandName: 'setSourceViewportForReferenceLinesTool',
|
||||
- context: 'CORNERSTONE',
|
||||
- }
|
||||
|
||||
+ {
|
||||
+ commandName: 'setViewportForToolConfiguration',
|
||||
+ commandOptions: {
|
||||
+ toolName: 'ReferenceLines'
|
||||
+ },
|
||||
+ context: 'CORNERSTONE',
|
||||
+ }
|
||||
```
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: General
|
||||
summary: General migration changes from OHIF 3.9 to 3.10, including Node.js version update, HTML template modifications, bundled Google Fonts, docs updates, faster development builds with rsbuild, and webpack configuration changes for AI segmentation support.
|
||||
---
|
||||
|
||||
## Node.js Version Update
|
||||
|
||||
We have updated the recommended Node.js version from `18.16.1` to `20.9.0`. Please ensure your development and build environments are using Node.js `20.9.0` or later.
|
||||
|
||||
## HTML Template Update
|
||||
We have modified the `template.html` file so if you are using a custom template, you will need to update it.
|
||||
|
||||
Here are the key changes needed in the migration:
|
||||
|
||||
1. Added `window.PUBLIC_URL` declaration:
|
||||
```javascript
|
||||
window.PUBLIC_URL = '<%= PUBLIC_URL %>';
|
||||
```
|
||||
|
||||
Was added before the `<!-- EXTENSIONS -->` comment block.
|
||||
|
||||
## Bundled Google Fonts
|
||||
|
||||
Previously, OHIF relied on the Google Fonts API to load the required fonts. To improve privacy, performance, and offline availability, we now bundle the necessary font files as assets within the application. No explicit action is required for this change unless you were specifically overriding or manipulating the font loading process.
|
||||
|
||||
You **might** need to update your `module` rule in your webpack
|
||||
|
||||
```javascript
|
||||
module.exports = {
|
||||
module: {
|
||||
rules: [
|
||||
{
|
||||
test: /\.(woff|woff2|eot|ttf|otf)$/i,
|
||||
type: 'asset/resource',
|
||||
},
|
||||
],
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## OHIF Docs
|
||||
|
||||
OHIF platform/docs is no longer part of the workspace.
|
||||
|
||||
- Builds are faster for 99.99% of users since only maintainers need to run the docs development.
|
||||
|
||||
If you need to run the docs website locally, you must install it first, as it is not installed by default.
|
||||
|
||||
Before:
|
||||
```bash
|
||||
yarn run dev
|
||||
```
|
||||
|
||||
After:
|
||||
```bash
|
||||
yarn install
|
||||
yarn run dev
|
||||
```
|
||||
|
||||
|
||||
## Experimental Fast Development Build (`dev:fast`)
|
||||
|
||||
We have introduced a new experimental command, `yarn run dev:fast`, which utilizes `rsbuild` and its Rust-based approach to significantly speed up development server start and hot module replacement times.
|
||||
|
||||
Here's a comparison of the performance improvements:
|
||||
|
||||
| Scenario | Load Time | Update Time |
|
||||
| -------- | ----------- | ----------- |
|
||||
| Before | ~12 seconds | ~5 seconds |
|
||||
| After | ~4 seconds | ~1 second |
|
||||
|
||||
**Note:** This command is currently experimental. While functional, it may not yet support all features or configurations of the standard `yarn run dev` command. We are continuing to develop and test this feature.
|
||||
|
||||
|
||||
## Webpack Configuration
|
||||
|
||||
To use our new Segmentation AI models, you'll need `onnxruntime-web`. If you're using a custom webpack configuration, make sure to update it with the new `copyPlugin` to copy the `onnxruntime-web` `dist` folder to your output directory.
|
||||
|
||||
|
||||
```javascript
|
||||
const CopyPlugin = require('copy-webpack-plugin');
|
||||
|
||||
module.exports = {
|
||||
plugins: [
|
||||
new CopyPlugin({
|
||||
patterns: [
|
||||
{
|
||||
from: '../../../node_modules/onnxruntime-web/dist',
|
||||
to: `${DIST_DIR}/ort`,
|
||||
},
|
||||
],
|
||||
}),
|
||||
],
|
||||
};
|
||||
```
|
||||
|
||||
Also, if you're running the viewer from a sub-route, you'll need to update the `dicom-microscopy-viewer` package in the dev server, so it knows where to load the assets from.
|
||||
|
||||
|
||||
```javascript
|
||||
devServer: {
|
||||
proxy: {
|
||||
'/dicom-microscopy-viewer': {
|
||||
target: 'http://localhost:3000',
|
||||
pathRewrite: {
|
||||
'^/dicom-microscopy-viewer': `/${PUBLIC_URL}/dicom-microscopy-viewer`,
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
```
|
||||
|
||||
:::note
|
||||
Also, the `writePluginImportFile` function has been updated so that the dicom-microscopy-viewer package works correctly with the new webpack configuration. If you have a custom `writePluginImportFile` function, please update it to match.
|
||||
:::
|
||||
+130
@@ -0,0 +1,130 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
title: Hotkeys
|
||||
summary: Migration guide for hotkeys management in OHIF 3.10, explaining the transition from defining hotkeys in mode factory to using the customizationService, with examples of replacing, adding, and modifying hotkey bindings.
|
||||
---
|
||||
|
||||
|
||||
## Key Changes:
|
||||
|
||||
* Hotkeys are no longer defined in mode factory via `hotkeys: [...hotkeys.defaults.hotkeyBindings]`
|
||||
* Hotkeys are now managed through the `customizationService` under the key `ohif.hotkeyBindings`
|
||||
* Default hotkeys are set automatically and can be customized using the customization service
|
||||
* User-defined hotkey preferences are now stored in a new format in localStorage
|
||||
* The `HotkeysManager` has undergone significant updates including better handling of defaults, key persistence, and cleanup
|
||||
|
||||
## Migration Steps:
|
||||
|
||||
### 1. Remove hotkeys array from mode factory definition
|
||||
|
||||
**Before:**
|
||||
```diff
|
||||
- function modeFactory({ modeConfiguration }) {
|
||||
- return {
|
||||
- id: 'basic',
|
||||
- // ... other configuration
|
||||
- hotkeys: [...hotkeys.defaults.hotkeyBindings],
|
||||
- };
|
||||
- }
|
||||
```
|
||||
|
||||
**After:**
|
||||
```diff
|
||||
+ function modeFactory({ modeConfiguration }) {
|
||||
+ return {
|
||||
+ id: 'basic',
|
||||
+ // ... other configuration
|
||||
+ // No hotkeys array necessary
|
||||
+ };
|
||||
+ }
|
||||
```
|
||||
|
||||
|
||||
### 2. Set custom hotkeys using the customization service
|
||||
|
||||
There are several methods to modify hotkeys using the customization service:
|
||||
|
||||
#### a. Completely replace all hotkeys using `$set`:
|
||||
|
||||
```diff
|
||||
+ onModeEnter: function ({ servicesManager }) {
|
||||
+ const { customizationService } = servicesManager.services;
|
||||
+ customizationService.setCustomizations({
|
||||
+ 'ohif.hotkeyBindings': {
|
||||
+ $set: [
|
||||
+ {
|
||||
+ commandName: 'setToolActive',
|
||||
+ commandOptions: { toolName: 'Zoom' },
|
||||
+ label: 'Zoom',
|
||||
+ keys: ['z'],
|
||||
+ isEditable: true,
|
||||
+ },
|
||||
+ ],
|
||||
+ },
|
||||
+ });
|
||||
```
|
||||
|
||||
#### b. Add new hotkeys using `$push`:
|
||||
|
||||
```diff
|
||||
+ onModeEnter: function ({ servicesManager }) {
|
||||
+ const { customizationService } = servicesManager.services;
|
||||
+ customizationService.setCustomizations({
|
||||
+ 'ohif.hotkeyBindings': {
|
||||
+ $push: [
|
||||
+ {
|
||||
+ commandName: 'myCustomCommand',
|
||||
+ label: 'My Custom Function',
|
||||
+ keys: ['ctrl+m'],
|
||||
+ isEditable: true,
|
||||
+ },
|
||||
+ ],
|
||||
+ },
|
||||
+ });
|
||||
+}
|
||||
```
|
||||
|
||||
### 4. Update configuration file if you were setting window.config.hotkeys
|
||||
|
||||
If you were previously defining hotkeys in your window.config.js file, it was not really
|
||||
taken into account. So you can safely remove it now.
|
||||
|
||||
**Before:**
|
||||
```diff
|
||||
- window.config = {
|
||||
- // ...other config
|
||||
- hotkeys: [
|
||||
- {
|
||||
- commandName: 'incrementActiveViewport',
|
||||
- label: 'Next Viewport',
|
||||
- keys: ['right'],
|
||||
- },
|
||||
- // ...more hotkeys
|
||||
- ],
|
||||
- };
|
||||
```
|
||||
|
||||
**After:**
|
||||
```diff
|
||||
+ window.config = {
|
||||
+ // ...other config
|
||||
+ };
|
||||
```
|
||||
|
||||
### 5. Be aware that user preferences are now handled differently
|
||||
|
||||
The new system automatically handles user-preferred hotkey mappings:
|
||||
|
||||
- User hotkey preferences are stored in `localStorage` under the key `user-preferred-keys`
|
||||
- The format is a hash-based mapping rather than a full array of definitions
|
||||
- There's a migration utility that converts old preferences to the new format
|
||||
- You don't need to manually handle this, but be aware of it if you're accessing localStorage directly
|
||||
|
||||
|
||||
## Benefits of the Change
|
||||
|
||||
1. **Consistent API**: Hotkeys now follow the same customization pattern as other OHIF features
|
||||
2. **More flexible**: Easier to modify specific hotkeys without replacing the entire set
|
||||
3. **Better user preferences**: User customizations are better preserved and migrated
|
||||
4. **Runtime updates**: Hotkeys can be modified at runtime through the customization service
|
||||
5. **Improved cleanup**: Better lifecycle management of hotkey bindings
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: routerBaseName
|
||||
summary: Migration guide for router configuration in OHIF 3.10, covering the updated default behavior of routerBasename and its interaction with PUBLIC_URL, with scenario-based examples for both root and subpath hosting.
|
||||
---
|
||||
|
||||
|
||||
## Migration Guide: Router Configuration (`routerBasename` and `PUBLIC_URL`)
|
||||
|
||||
|
||||
**Key Changes:**
|
||||
|
||||
* **`routerBasename` Default Value:** The recommended default value for `routerBasename` in the configuration file (`window.config`) has changed from `'/'` to `null`.
|
||||
* **New Default Behavior:** If `routerBasename` is set to `null` (or is not defined) in the configuration, the application's base path will now automatically default to the value determined by `PUBLIC_URL`.
|
||||
* **Clarified Roles:**
|
||||
* `routerBasename`: Explicitly defines the base path for the application's routes (e.g., `/viewer`). If `null`, it defaults to `PUBLIC_URL`.
|
||||
* `PUBLIC_URL`: Primarily defines the URL prefix from which static assets (like JavaScript files, CSS, images) are loaded. It defaults to `/` if not set.
|
||||
|
||||
|
||||
:::info
|
||||
see the comprehensive guide [here](/deployment/custom-url-access)
|
||||
:::
|
||||
|
||||
**Migration Steps:**
|
||||
|
||||
1. **Review `routerBasename` Configuration:**
|
||||
Locate the `routerBasename` setting within your application configuration file (typically found in `platform/app/public/config/*.js`).
|
||||
|
||||
2. **Update `routerBasename` Based on Hosting Scenario:**
|
||||
|
||||
* **Scenario A: Hosting at the Root (`/`)**
|
||||
If your application is served from the root domain (e.g., `https://example.com/`), it's recommended to update `routerBasename` to `null`. This aligns the routing base with the default asset loading path (`PUBLIC_URL` which defaults to `/`).
|
||||
|
||||
*Example Diff:*
|
||||
```diff
|
||||
window.config = {
|
||||
- routerBasename: '/',
|
||||
+ routerBasename: null,
|
||||
// ... other config options
|
||||
showStudyList: true,
|
||||
dataSources: [ /* ... */ ],
|
||||
```
|
||||
*Explanation:* Setting `routerBasename: null` leverages the new default behavior. The router will use `/` as its base because `PUBLIC_URL` defaults to `/`.
|
||||
|
||||
* **Scenario B: Hosting at a Subpath (e.g., `/viewer/`)**
|
||||
If your application is served from a subpath (e.g., `https://example.com/viewer/`), you should ensure `routerBasename` is explicitly set to that path.
|
||||
|
||||
*Example (No Change Needed if Already Correct):*
|
||||
```diff
|
||||
window.config = {
|
||||
// No change needed if already set correctly for subpath hosting
|
||||
routerBasename: '/viewer',
|
||||
// ... other config options
|
||||
showStudyList: true,
|
||||
dataSources: [ /* ... */ ],
|
||||
```
|
||||
*Explanation:* Explicitly setting `routerBasename` ensures the application's internal routing works correctly under the `/viewer/` path.
|
||||
Reference in new issue
Block a user