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
@@ -0,0 +1,72 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
sidebar_label: Commands
|
||||
summary: Migration guide for OHIF 3.11's different commands
|
||||
---
|
||||
|
||||
|
||||
|
||||
## updateStoredPositionPresentation
|
||||
|
||||
now uses displaySetInstanceUIDs instead of displaySetInstanceUID as a parameter.
|
||||
|
||||
|
||||
## `loadSRMeasurements` Command
|
||||
|
||||
**Key Changes:**
|
||||
|
||||
* The `loadSRMeasurements` command, previously part of the `@ohif/extension-cornerstone-dicom-sr` extension, has been **removed**.
|
||||
* Its functionality of hydrating a Structured Report (SR) and displaying its referenced series in a viewport is now primarily handled by the new `hydrateSecondaryDisplaySet` command available in the `@ohif/extension-cornerstone` extension.
|
||||
* The `hydrateStructuredReport` command (from `@ohif/extension-cornerstone-dicom-sr`) now solely focuses on hydrating the SR and returning its data, without directly manipulating viewports.
|
||||
|
||||
**Migration Steps:**
|
||||
|
||||
If you were previously using the `loadSRMeasurements` command to load and display SR measurements, you should update your code to use the `hydrateSecondaryDisplaySet` command.
|
||||
|
||||
1. **Identify `loadSRMeasurements` Usage:**
|
||||
Locate where your code calls `commandsManager.runCommand('loadSRMeasurements', ...)`.
|
||||
|
||||
2. **Update to `hydrateSecondaryDisplaySet`:**
|
||||
Replace the call to `loadSRMeasurements` with `hydrateSecondaryDisplaySet`. You will need to pass the full `displaySet` object for the SR and the target `viewportId`.
|
||||
|
||||
```diff
|
||||
- // Old way: using loadSRMeasurements
|
||||
- commandsManager.runCommand('loadSRMeasurements', {
|
||||
- displaySetInstanceUID: srDisplaySetInstanceUID,
|
||||
- // viewportId was implicitly the active one or not directly specifiable here
|
||||
- });
|
||||
-
|
||||
+ // New way: using hydrateSecondaryDisplaySet
|
||||
+ const { displaySetService, viewportGridService } = servicesManager.services;
|
||||
+
|
||||
+ // 1. Get the SR displaySet object
|
||||
+ const srDisplaySet = displaySetService.getDisplaySetByUID(srDisplaySetInstanceUID);
|
||||
+
|
||||
+ // 2. Determine the target viewportId (e.g., active viewport)
|
||||
+ const viewportId = viewportGridService.getActiveViewportId(); // Or your specific viewportId
|
||||
+
|
||||
+ if (srDisplaySet && viewportId) {
|
||||
+ commandsManager.runCommand('hydrateSecondaryDisplaySet', {
|
||||
+ displaySet: srDisplaySet,
|
||||
+ viewportId: viewportId,
|
||||
+ });
|
||||
+ } else {
|
||||
+ console.warn('SR DisplaySet or ViewportId not found, cannot hydrate.');
|
||||
+ }
|
||||
```
|
||||
|
||||
**Explanation:**
|
||||
|
||||
* The `loadSRMeasurements` command was responsible for both hydrating the SR (getting its measurement data and referenced series UIDs) and then updating the viewport to show the referenced series.
|
||||
* The new `hydrateSecondaryDisplaySet` command, when given an SR `displaySet` (`displaySet.Modality === 'SR'`), will:
|
||||
1. Internally call the `hydrateStructuredReport` command to parse the SR and get its details (including `SeriesInstanceUIDs` of referenced images).
|
||||
2. Then, it will automatically find the corresponding image display sets for those `SeriesInstanceUIDs`.
|
||||
3. Finally, it will update the specified `viewportId` to display the primary referenced image series.
|
||||
* This change centralizes the logic for hydrating secondary display sets (like SR, SEG, RTSTRUCT) and updating viewports into the `hydrateSecondaryDisplaySet` command within the core Cornerstone extension.
|
||||
|
||||
**Note on UI/Button Changes:**
|
||||
The UI button typically associated with "Load SR" (often seen in viewport corners or specific contexts) has also been refactored. The hydration of SRs is now often triggered by:
|
||||
* The `TrackedMeasurementsContext` if the `@ohif/extension-measurement-tracking` is in use.
|
||||
* The new `ModalityLoadBadge` component, which can appear in viewports containing SR, SEG, or RTSTRUCT display sets, offering a "LOAD" action that calls `hydrateSecondaryDisplaySet`.
|
||||
|
||||
If you had custom UI invoking `loadSRMeasurements`, you'll need to adapt it to call `hydrateSecondaryDisplaySet` as described above.
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: Hydration
|
||||
sidebar_position: 3
|
||||
sidebar_label: Hydration
|
||||
summary: Migration guide for OHIF 3.11's hydration system changes, including the transition to a centralized hydration dialog and command-based hydration for secondary display sets.
|
||||
---
|
||||
|
||||
## Update Hydration Logic:
|
||||
* The `promptHydrateSEG` and `promptHydrateRT` functions have been updated to use the generic `utils.promptHydrationDialog` from `@ohif/extension-cornerstone`.
|
||||
* The actual hydration is now often triggered by the `hydrateSecondaryDisplaySet` command.
|
||||
|
||||
*Example: `promptHydrateRT` change*
|
||||
|
||||
```diff
|
||||
// extensions/cornerstone-dicom-rt/src/utils/promptHydrateRT.ts
|
||||
- const RESPONSE = {
|
||||
- NO_NEVER: -1,
|
||||
- CANCEL: 0,
|
||||
- HYDRATE_SEG: 5,
|
||||
- };
|
||||
+ import { utils, Types } from '@ohif/extension-cornerstone';
|
||||
|
||||
function promptHydrateRT({
|
||||
servicesManager,
|
||||
rtDisplaySet,
|
||||
viewportId,
|
||||
preHydrateCallbacks,
|
||||
hydrateRTDisplaySet,
|
||||
-}: withAppTypes) {
|
||||
- const { uiViewportDialogService, customizationService } = servicesManager.services;
|
||||
- // ... lots of old promise and dialog logic
|
||||
- return new Promise(async function (resolve, reject) {
|
||||
- // ...
|
||||
- });
|
||||
-}
|
||||
-
|
||||
-function _askHydrate(
|
||||
- // ...
|
||||
-) {
|
||||
- // ...
|
||||
-}
|
||||
+}: {
|
||||
+ servicesManager: AppTypes.ServicesManager;
|
||||
+ rtDisplaySet: AppTypes.DisplaySet;
|
||||
+ viewportId: string;
|
||||
+ preHydrateCallbacks?: Types.HydrationCallback[];
|
||||
+ hydrateRTDisplaySet: Types.HydrationCallback;
|
||||
+}) {
|
||||
+ return utils.promptHydrationDialog({
|
||||
+ servicesManager,
|
||||
+ viewportId,
|
||||
+ displaySet: rtDisplaySet,
|
||||
+ preHydrateCallbacks,
|
||||
+ hydrateCallback: hydrateRTDisplaySet,
|
||||
+ type: 'RTSTRUCT',
|
||||
+ });
|
||||
}
|
||||
```
|
||||
The `hydrateRTDisplaySet` callback passed to this function would now typically involve the `hydrateSecondaryDisplaySet` command.
|
||||
```diff
|
||||
// extensions/cornerstone-dicom-rt/src/viewports/OHIFCornerstoneRTViewport.tsx
|
||||
useEffect(() => {
|
||||
if (rtIsLoading) {
|
||||
return;
|
||||
}
|
||||
promptHydrateRT({
|
||||
servicesManager,
|
||||
viewportId,
|
||||
rtDisplaySet,
|
||||
- preHydrateCallbacks: [storePresentationState],
|
||||
- hydrateRTDisplaySet,
|
||||
- }).then(isHydrated => {
|
||||
- if (isHydrated) {
|
||||
- setIsHydrated(true);
|
||||
- }
|
||||
+ hydrateRTDisplaySet: async () => {
|
||||
+ return commandsManager.runCommand('hydrateSecondaryDisplaySet', {
|
||||
+ displaySet: rtDisplaySet,
|
||||
+ viewportId,
|
||||
+ });
|
||||
+ },
|
||||
});
|
||||
- }, [servicesManager, viewportId, rtDisplaySet, rtIsLoading]);
|
||||
+ }, [servicesManager, viewportId, rtDisplaySet, rtIsLoading, commandsManager]);
|
||||
```
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
sidebar_label: 3.10 -> 3.11
|
||||
---
|
||||
|
||||
# Migration Guide
|
||||
|
||||
This guide provides information about migrating from OHIF version 3.10 to version 3.11.
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
sidebar_label: Other Changes
|
||||
summary: Migration guide for OHIF 3.11 additional changes
|
||||
---
|
||||
|
||||
|
||||
**Key Changes:**
|
||||
|
||||
* **`connectToolsToMeasurementService` parameters:** The `connectToolsToMeasurementService` function from the `@ohif/cornerstone-extensions` now take different arguments.
|
||||
* **`data-viewportId`** The `data-viewportId` naming was not compliant with react and was causing warnings. Rename references to `data-viewportid`.
|
||||
* **`setIsReferenceViewable`** is no longer available or required by ViewportGridService. Instead, the cornerstone viewports
|
||||
themselves provide the isReferenceViewable. This occurs because there were a lot more deciding issues to navigate to viewports than could be added to viewport grid service.
|
||||
* **`JUMP_TO_MEASUREMENT_VIEWPORT` and `JUMP_TO_MEASUREMENT_LAYOUT`** are combined into `JUMP_TO_MEASUREMENT` with no
|
||||
consume event. Only the single event is fired. This will need to be handled to redirect the changes to the appropriate viewport type as it was not possible to figure that out with generic information available in `ViewportGridService`
|
||||
|
||||
**Migration Steps:**
|
||||
|
||||
1. **Update `connectToolsToMeasurementService` Method Calls:**
|
||||
* Now the connectToolsToMeasurementService receives all service object arguments (servicesManager, commandsManager and extensionManager).
|
||||
|
||||
```diff
|
||||
// Before
|
||||
- connectToolsToMeasurementService(servicesManager);
|
||||
|
||||
// After
|
||||
+ connectToolsToMeasurementService({
|
||||
+ servicesManager,
|
||||
+ commandsManager,
|
||||
+ extensionsManager
|
||||
+ });
|
||||
```
|
||||
|
||||
**Images sort by position patient**
|
||||
|
||||
The ImageSet sort has been modified: images are now sorted by ImagePositionPatient by default. If ImagePositionPatient is not available, the sort will fall back to InstanceNumber.
|
||||
|
||||
**To revert to the previous sorting method, you can add the customization instanceSortingCriteria as shown below:**
|
||||
|
||||
```
|
||||
customizationService.setCustomizations({
|
||||
'instanceSortingCriteria': {
|
||||
$set: {defaultSortFunctionName: 'default'},
|
||||
},
|
||||
});
|
||||
```
|
||||
+178
@@ -0,0 +1,178 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
sidebar_label: Toolbar Service
|
||||
summary: Migration guide for OHIF 3.11's toolbar service changes, including the transition from `ViewportActionCornersService` to `ToolbarService`
|
||||
---
|
||||
|
||||
|
||||
**Key Changes:**
|
||||
|
||||
* **`ViewportActionCornersService` Removed:** The `ViewportActionCornersService` and its associated provider (`ViewportActionCornersProvider`) and hook (`useViewportActionCorners`) have been removed. Functionality for viewport corner items is now integrated into the `ToolbarService` and standard toolbar components.
|
||||
* **Viewport Corner Items as Toolbar Buttons:** Items previously managed by `ViewportActionCornersService` are now configured as regular toolbar buttons. They are assigned to specific toolbar sections (e.g., `viewportActionMenu.topLeft`) and rendered using `Toolbar` components within the viewport corners.
|
||||
* **`ToolbarService` API Updates:**
|
||||
* `ToolbarService.addButtons()` has been renamed to `ToolbarService.register()` to better reflect its purpose of registering button definitions rather than just adding them.
|
||||
* `ToolbarService.createButtonSection()` has been renamed to `ToolbarService.updateSection()` to better reflect that it is not about creating new sections but updating existing ones.
|
||||
* `ToolbarService` now has a `sections` property (e.g., `toolbarService.sections.viewportActionMenu.topLeft`) providing predefined section names.
|
||||
* **Enhanced `useToolbar` Hook:**
|
||||
* The `useToolbar` hook now returns additional state management functions for toolbar items:
|
||||
* `openItem`, `closeItem`, `isItemOpen` (for managing dropdown/popover states).
|
||||
* `lockItem`, `unlockItem`, `toggleLock`, `isItemLocked`.
|
||||
* `showItem`, `hideItem`, `toggleVisibility`, `isItemVisible`.
|
||||
* The `onInteraction` callback now receives `itemId` and `viewportId`.
|
||||
* **Toolbar Button Configuration:**
|
||||
* The `groupId` prop in button configurations (e.g., for `ohif.toolButtonList`, `ohif.toolBoxButtonGroup`) is generally replaced by directly using `buttonSection` to define the set of buttons.
|
||||
* Button `evaluate` functions can now leverage `evaluateProps.hideWhenDisabled` to automatically hide a button when it's disabled.
|
||||
* **New UI Components & Hooks for Viewport Corners:**
|
||||
* Specialized components like `ModalityLoadBadge`, `NavigationComponent`, `TrackingStatus`, `ViewportDataOverlayMenuWrapper`, `ViewportOrientationMenuWrapper`, `WindowLevelActionMenuWrapper` are now used as toolbar buttons, typically in viewport action menu sections.
|
||||
* `useViewportHover` hook can be used to determine if a viewport is hovered or active, controlling the visibility of corner toolbars.
|
||||
* **`IconPresentationProvider`:** A new `IconPresentationProvider` and `useIconPresentation` hook have been introduced to standardize icon sizing and styling within toolbars and related components.
|
||||
* **Legacy Toolbar Components Removed:** `ToolbarSplitButtonWithServicesLegacy` and `ToolbarButtonGroupWithServicesLegacy` have been removed.
|
||||
|
||||
**Migration Steps:**
|
||||
|
||||
1. **Update `ToolbarService` Method Calls:**
|
||||
* Although the previous method also works but gives warning in the console when used.
|
||||
* Replace all instances of `toolbarService.addButtons(...)` with `toolbarService.register(...)`.
|
||||
* Replace all instances of `toolbarService.createButtonSection(...)` with `toolbarService.updateSection(...)`.
|
||||
|
||||
```diff
|
||||
// Before
|
||||
- toolbarService.addButtons(toolbarButtons);
|
||||
- toolbarService.createButtonSection('primary', ['Zoom', 'Pan']);
|
||||
|
||||
// After
|
||||
+ toolbarService.register(toolbarButtons);
|
||||
+ toolbarService.updateSection('primary', ['Zoom', 'Pan']);
|
||||
```
|
||||
|
||||
2. **Migrate Viewport Action Corner Items:**
|
||||
* Remove any direct usage of the old `ViewportActionCornersService`, `useViewportActionCorners`, or `ViewportActionCornersProvider`.
|
||||
* Define your viewport corner items (like orientation menu, W/L menu, data overlay menu) as standard toolbar buttons using `toolbarService.register()`.
|
||||
* Assign these buttons to the new dedicated viewport action menu sections. You can access these section names via `toolbarService.sections.viewportActionMenu.<location>`, e.g., `toolbarService.sections.viewportActionMenu.topLeft`.
|
||||
|
||||
```diff
|
||||
// Before: Customization in viewportActionMenuCustomizations.ts (now deleted)
|
||||
// or direct use of ViewportActionCornersService.addComponent
|
||||
- // Example: viewportActionCornersService.addComponent({ viewportId, id: 'orientationMenu', component: MyOrientationMenu, location: 'topLeft' });
|
||||
|
||||
// After: In your mode's onModeEnter or similar setup
|
||||
+ const myViewportCornerButtons = [
|
||||
+ {
|
||||
+ id: 'orientationMenu',
|
||||
+ uiType: 'ohif.orientationMenu', // Or your custom component registered as a UI type
|
||||
+ props: { /* ... props for your component ... */ }
|
||||
+ },
|
||||
+ // ... other corner buttons
|
||||
+ ];
|
||||
+ toolbarService.register(myViewportCornerButtons);
|
||||
+ toolbarService.updateSection(
|
||||
+ toolbarService.sections.viewportActionMenu.topLeft,
|
||||
+ ['orientationMenu', /* other button IDs */]
|
||||
+ );
|
||||
```
|
||||
* The `OHIFViewportActionCorners.tsx` component now internally uses `Toolbar` components for each corner, which are populated by these sections.
|
||||
* For custom components that act as menus (e.g., popovers), use the `onOpen`, `onClose`, `isOpen` props passed down by the `Toolbar` component (which get these from `useToolbar`).
|
||||
|
||||
```diff
|
||||
// Before: Custom component might have managed its own open state
|
||||
- // const [isMenuOpen, setIsMenuOpen] = useState(false);
|
||||
- // const handleOpenChange = (open) => setIsMenuOpen(open);
|
||||
|
||||
// After: Custom component receives isOpen, onOpen, onClose from Toolbar
|
||||
+ function MyCustomMenuButton({ isOpen, onOpen, onClose, ...rest }) {
|
||||
+ const handleOpenChange = (openState: boolean) => {
|
||||
+ if (openState) {
|
||||
+ onOpen?.();
|
||||
+ } else {
|
||||
+ onClose?.();
|
||||
+ }
|
||||
+ };
|
||||
+
|
||||
+ return (
|
||||
+ <Popover open={isOpen} onOpenChange={handleOpenChange}>
|
||||
+ {/* ... PopoverTrigger and PopoverContent ... */}
|
||||
+ </Popover>
|
||||
+ );
|
||||
+ }
|
||||
```
|
||||
|
||||
3. **Adapt Toolbar Button and Component Configurations:**
|
||||
|
||||
The configuration of toolbar buttons, especially how they relate to sections
|
||||
|
||||
* **Button Section Association via `props.buttonSection`:**
|
||||
|
||||
The toolbar service now offers two ways to define this association:
|
||||
|
||||
* **A. Simple Approach: `buttonSection: true` (Implicitly Uses Button's Own ID)**
|
||||
|
||||
If a button definition includes `props: { buttonSection: true }`, the `ToolbarService` automatically sets the effective `buttonSection` ID to be the same as the button's own `id`.
|
||||
|
||||
```javascript
|
||||
// Example: A ToolButtonList component's definition in toolbarButtons.ts
|
||||
// {
|
||||
// id: 'MeasurementTools', // ID of this ToolButtonList component
|
||||
// uiType: 'ohif.toolButtonList',
|
||||
// props: {
|
||||
// buttonSection: true // This ToolButtonList will render the section named 'MeasurementTools'
|
||||
// }
|
||||
// }
|
||||
```
|
||||
|
||||
later you can use it like
|
||||
|
||||
|
||||
```javascript
|
||||
toolbarService.updateSection('MeasurementTools', ['Length', 'Bidirectional', ...]);
|
||||
```
|
||||
|
||||
* **B. Flexible Approach: `buttonSection: 'customSectionName'` (Explicit Section ID)**
|
||||
|
||||
You can explicitly provide a string for `props.buttonSection` if the button should be associated with a section ID that is different from its own `id`, or if you prefer explicit naming.
|
||||
|
||||
```javascript
|
||||
// Example: A ToolButtonList component's definition
|
||||
// {
|
||||
// id: 'MySpecialToolList', // ID of this ToolButtonList component
|
||||
// uiType: 'ohif.toolButtonList',
|
||||
// props: {
|
||||
// buttonSection: 'toolsForAdvancedUsers', // This list renders 'toolsForAdvancedUsers' section
|
||||
// }
|
||||
// }
|
||||
```
|
||||
|
||||
* **`evaluate` Function Enhancement:**
|
||||
* Button `evaluate` functions can now leverage `evaluateProps: { hideWhenDisabled: true }` in your button definition to automatically hide a button when it's disabled.
|
||||
|
||||
* **Wrapper Component `onInteraction` (e.g., `ToolButtonListWrapper`):**
|
||||
* Update wrappers like `ToolBoxButtonGroupWrapper` and `ToolButtonListWrapper`:
|
||||
* The `groupId` prop is replaced by `id` (which is the ID of the wrapper button component itself).
|
||||
* The `onInteraction` callback in these wrappers now provides `id` (the wrapper's ID) instead of `groupId`.
|
||||
|
||||
|
||||
4. **Adopt `IconPresentationProvider` (Optional but Recommended):**
|
||||
* For consistent icon styling across your application's toolbars, wrap a high-level component (like your main `Header` or layout component) with `<IconPresentationProvider size="yourDefaultSize">`.
|
||||
* Custom tool button components can then use the `useIconPresentation` hook to get appropriate class names for icons or a pre-styled `IconContainer`.
|
||||
|
||||
```diff
|
||||
// In your main App.tsx or Header.tsx
|
||||
+ import { IconPresentationProvider, ToolButton } from '@ohif/ui-next';
|
||||
// ...
|
||||
+ <IconPresentationProvider
|
||||
+ size="large" // Or "medium", "small", "tiny", or a number
|
||||
+ IconContainer={ToolButton} // Optional: default is Button
|
||||
+ containerProps={{ variant: 'primary', className: 'custom-container-class' }} // Optional
|
||||
+ >
|
||||
{/* Your Header content including Toolbars */}
|
||||
+ </IconPresentationProvider>
|
||||
|
||||
// In a custom tool button using icons
|
||||
+ import { useIconPresentation, Icons } from '@ohif/ui-next';
|
||||
+ function MyCustomToolButton({ iconName }) {
|
||||
+ const { className: iconClassName } = useIconPresentation();
|
||||
+ return <button><Icons.ByName name={iconName} className={iconClassName} /></button>;
|
||||
+ }
|
||||
```
|
||||
|
||||
5. **Remove Legacy Component Usage:**
|
||||
* Replace any usage of `ToolbarSplitButtonWithServicesLegacy` and `ToolbarButtonGroupWithServicesLegacy` with the newer patterns, typically by configuring individual buttons and using `ToolButtonList` or `ButtonGroup` from `@ohif/ui-next` directly, driven by `useToolbar`.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
sidebar_position: 5
|
||||
sidebar_label: UI
|
||||
summary: Migration guide for OHIF 3.11's UI changes, including the transition from `ViewportActionCornersService` to `ToolbarService` and the introduction of `useToolbar` hook.
|
||||
---
|
||||
|
||||
|
||||
## New useIconPresentation hook
|
||||
|
||||
This section details the introduction of the `IconPresentationProvider` and `useIconPresentation` hook, offering an optional way to manage icon size and container styling within the UI.
|
||||
|
||||
### Key Changes:
|
||||
|
||||
* **New Context and Hook:** Introduction of `IconPresentationProvider` and `useIconPresentation` to provide a standardized way to control the size and potentially the container component/props for icons and related interactive elements (like `ToolButton`).
|
||||
|
||||
### Migration Steps:
|
||||
|
||||
Using the `IconPresentationProvider` is **entirely optional**. If you do not wrap your components with this provider, components like `ToolButton` will continue to use their explicit `size` prop and default styling.
|
||||
|
||||
However, if you wish to centrally manage the presentation of icons within a specific part of your application's component tree, follow these steps:
|
||||
|
||||
1. **Identify the component subtree:** Determine which section of your UI you want to apply consistent icon styling to.
|
||||
|
||||
2. **Wrap with `IconPresentationProvider`:** Wrap the root of that component subtree with the `IconPresentationProvider`. Pass the desired `size` prop. You can also optionally provide a custom `IconContainer` component and `containerProps` if you want to change the wrapper around the icon itself (e.g., switching from a `Button` to a `ToolButton` or applying specific styling).
|
||||
|
||||
```jsx
|
||||
import { IconPresentationProvider, ToolButton } from '@ohif/ui-next';
|
||||
|
||||
function MyComponentTree() {
|
||||
return (
|
||||
// Icons and ToolButtons within this provider will inherit 'large' size
|
||||
<IconPresentationProvider size="large">
|
||||
{/* Any components inside that consume the context */}
|
||||
<ToolButton id="myTool" icon="Circle" tooltip="Draw Circle" />
|
||||
{/* ... other components ... */}
|
||||
</IconPresentationProvider>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
3. **Consume the context in components (if building custom components):** If you are building a custom component that renders an icon and want it to respect the provider's settings, use the `useIconPresentation` hook within that component. This hook provides the configured size, a calculated CSS class name (`className`), the specified `IconContainer` component, and its `containerProps`.
|
||||
|
||||
```jsx
|
||||
import React from 'react';
|
||||
import { useIconPresentation, Icons } from '@ohif/ui-next';
|
||||
|
||||
function MyCustomIconButton({ iconName, ...rest }) {
|
||||
// This hook reads the nearest IconPresentationProvider context
|
||||
const { className, IconContainer, containerProps } = useIconPresentation();
|
||||
|
||||
// Use the provided IconContainer and its props
|
||||
return (
|
||||
<IconContainer {...rest} {...containerProps}>
|
||||
{/* Use the calculated className for the icon */}
|
||||
<Icons.ByName name={iconName} className={className} />
|
||||
</IconContainer>
|
||||
);
|
||||
}
|
||||
```
|
||||
*Note: Built-in components like `ToolButton` in `@ohif/ui-next` have been updated internally to consume this context automatically if a provider is available.*
|
||||
+124
@@ -0,0 +1,124 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
sidebar_label: Viewport Corners
|
||||
summary: Migration guide for OHIF 3.11's viewport corners customization changes, including the transition from individual item configurations to location-based arrays and the removal of index priorities.
|
||||
---
|
||||
|
||||
|
||||
Okay, here's a migration guide based on the provided diff, focusing on the introduction of `TrackingStatus`, `ModalityLoadBadge`, and `NavigationComponent`.
|
||||
|
||||
**Key Changes:**
|
||||
|
||||
* **Deprecated `ViewportActionCornersService`**: The `ViewportActionCornersService` and its associated provider (`ViewportActionCornersProvider`) have been removed. UI elements previously managed by this service are now typically handled by dedicated components integrated via the `ToolbarService`.
|
||||
* **New Centralized UI Components**:
|
||||
* `ModalityLoadBadge`: A new component in `@ohif/extension-cornerstone` that displays the status (e.g., SEG/RT/SR loaded or requiring hydration) and a "LOAD" button for secondary display sets (SEG, RTSTRUCT, SR). This replaces the inline status and load logic within individual viewport components like `OHIFCornerstoneSEGViewport` and `OHIFCornerstoneRTViewport`.
|
||||
* `TrackingStatus`: A new component in `@ohif/extension-cornerstone` to indicate if measurements in a viewport are being tracked. This replaces inline tracking status indicators previously in `OHIFCornerstoneSRMeasurementViewport` and `TrackedCornerstoneViewport`.
|
||||
* `NavigationComponent`: A new component in `@ohif/extension-cornerstone` that provides navigation arrows (e.g., for segments in SEG/RT or measurements in SR/tracked series). This replaces the `ViewportActionArrows` previously instantiated directly within viewport components.
|
||||
* **Viewport Simplification**: Viewport components like `OHIFCornerstoneSEGViewport`, `OHIFCornerstoneRTViewport`, and `OHIFCornerstoneSRMeasurementViewport` have been simplified. They no longer manage their own status indicators, load buttons, or navigation arrows. They now primarily delegate rendering to `OHIFCornerstoneViewport`.
|
||||
* **Refactored Hydration Prompts**: Utility functions like `promptHydrateSEG` and `promptHydrateRT` now use a centralized `utils.promptHydrationDialog` from `@ohif/extension-cornerstone`.
|
||||
* **Centralized Hydration Command**: A new command `hydrateSecondaryDisplaySet` has been added to `@ohif/extension-cornerstone` to handle the hydration logic for SEG, RTSTRUCT, and SR display sets.
|
||||
* **New Hooks**: Several new hooks have been introduced in `@ohif/extension-cornerstone` (e.g., `useViewportDisplaySets`, `useMeasurementTracking`, `useViewportSegmentations`, `useViewportHover`) to provide data and state for these new UI components.
|
||||
|
||||
**Migration Steps:**
|
||||
|
||||
1. **Remove `ViewportActionCornersService` Usage**:
|
||||
* If you were using `ViewportActionCornersService` to add custom components to viewport corners, you will need to refactor this. The recommended approach is to define these components as toolbar buttons and place them in designated viewport action menu sections (e.g., `viewportActionMenu.topLeft`) using the `ToolbarService`.
|
||||
* The internal status components (`_getStatusComponent`) and `ViewportActionArrows` within specific viewports (SEG, RT, SR) have been removed. Their functionality is now provided by `ModalityLoadBadge`, `TrackingStatus`, and `NavigationComponent`.
|
||||
|
||||
|
||||
3. **Integrate New UI Components via `ToolbarService`**:
|
||||
* The `ModalityLoadBadge`, `TrackingStatus`, and `NavigationComponent` are now registered with the `ToolbarService` within the `@ohif/extension-cornerstone`'s `getToolbarModule`.
|
||||
* Modes (e.g., `longitudinal`) should define toolbar sections for viewport corners and add these components to those sections.
|
||||
|
||||
*Example: Adding components to viewport corners in `longitudinal` mode*
|
||||
```diff
|
||||
// modes/longitudinal/src/index.ts
|
||||
function modeFactory({ modeConfiguration }) {
|
||||
return {
|
||||
// ...
|
||||
onModeEnter: ({ servicesManager, extensionManager, commandsManager }: withAppTypes) => {
|
||||
// ...
|
||||
toolbarService.addButtons(toolbarButtons);
|
||||
toolbarService.createButtonSection('primary', [
|
||||
// ... primary tools
|
||||
]);
|
||||
|
||||
+ toolbarService.updateSection(toolbarService.sections.viewportActionMenu.topLeft, [
|
||||
+ 'orientationMenu',
|
||||
+ 'dataOverlayMenu',
|
||||
+ 'windowLevelMenu',
|
||||
+ ]);
|
||||
+ toolbarService.updateSection(toolbarService.sections.viewportActionMenu.topRight, [
|
||||
+ 'modalityLoadBadge',
|
||||
+ 'trackingStatus',
|
||||
+ 'navigationComponent',
|
||||
+ ]);
|
||||
// ...
|
||||
},
|
||||
```
|
||||
And ensure these buttons are defined in your mode's `toolbarButtons.ts`:
|
||||
```diff
|
||||
// modes/longitudinal/src/toolbarButtons.ts
|
||||
+ {
|
||||
+ id: 'modalityLoadBadge',
|
||||
+ uiType: 'ohif.modalityLoadBadge',
|
||||
+ props: {
|
||||
+ // ... props like icon, label, tooltip, evaluate
|
||||
+ evaluate: {
|
||||
+ name: 'evaluate.modalityLoadBadge',
|
||||
+ hideWhenDisabled: true,
|
||||
+ },
|
||||
+ },
|
||||
+ },
|
||||
+ {
|
||||
+ id: 'navigationComponent',
|
||||
+ uiType: 'ohif.navigationComponent',
|
||||
+ props: {
|
||||
+ // ... props
|
||||
+ evaluate: {
|
||||
+ name: 'evaluate.navigationComponent',
|
||||
+ hideWhenDisabled: true,
|
||||
+ },
|
||||
+ },
|
||||
+ },
|
||||
+ {
|
||||
+ id: 'trackingStatus',
|
||||
+ uiType: 'ohif.trackingStatus',
|
||||
+ props: {
|
||||
+ // ... props
|
||||
+ evaluate: {
|
||||
+ name: 'evaluate.trackingStatus',
|
||||
+ hideWhenDisabled: true,
|
||||
+ },
|
||||
+ },
|
||||
+ },
|
||||
```
|
||||
|
||||
|
||||
5. **Direct Import of `OHIFCornerstoneViewport`**:
|
||||
* Extensions that were previously getting the cornerstone viewport component dynamically via `extensionManager.getModuleEntry('@ohif/extension-cornerstone.viewportModule.cornerstone')` should now import `OHIFCornerstoneViewport` directly from `@ohif/extension-cornerstone`.
|
||||
|
||||
```diff
|
||||
// extensions/cornerstone-dicom-pmap/src/viewports/OHIFCornerstonePMAPViewport.tsx
|
||||
import PropTypes from 'prop-types';
|
||||
import React, { useCallback, useEffect, useRef, useState } from 'react';
|
||||
import { useViewportGrid } from '@ohif/ui-next';
|
||||
+import { OHIFCornerstoneViewport } from '@ohif/extension-cornerstone';
|
||||
|
||||
function OHIFCornerstonePMAPViewport(props: withAppTypes) {
|
||||
// ...
|
||||
const getCornerstoneViewport = useCallback(() => {
|
||||
- const { component: Component } = extensionManager.getModuleEntry(
|
||||
- '@ohif/extension-cornerstone.viewportModule.cornerstone'
|
||||
- );
|
||||
// ...
|
||||
return (
|
||||
- <Component
|
||||
+ <OHIFCornerstoneViewport
|
||||
{...props}
|
||||
// ...
|
||||
- ></Component>
|
||||
+ />
|
||||
);
|
||||
// ...
|
||||
```
|
||||
Reference in new issue
Block a user