feat: Add customization support for UI components

[abhijith-trenser]

Context

• Created a custom hook and provider to manage and share services across the application.
• Added support for rendering custom UI components.
• This PR has been incorporated by FlyWheel.io

Changes & Results

• Developed a new hook and provider for accessing services directly across the application, eliminating the need to pass them through props.
• By using the new CustomizableRenderingComponents, we made changes to the following components to support receiving custom components through the customization service.

1. LabellingFlow,
2. LoadingIndicatorProgress,
3. LoadingIndicatorTotalPercent,
4. ProgressLoadingBar,
5. ContextMenuItem,
6. ViewportActionCorners

• As part of this, we moved the default OSS components to the extensions/default and extensions/cornerstone folders and now send the default components through the customization module.
• This allows users to replace these components with their own customizations, either in mode or global customizations.

Testing

• Set a new component through the customization service using the corresponding customizationId for the mentioned components.
• Observe the behavior in the viewer.
• The newly set component should replace the default OSS component.

Checklist

PR

• My Pull Request title is descriptive, accurate and follows the
  semantic-release format and guidelines.

Code

• My code has been well-documented (function documentation, inline comments,
  etc.)

Public Documentation Updates

• The documentation page has been updated as necessary for any public API
  additions or removals.

Tested Environment

• OS: Windows 10
• Node version: 18.19.0
• Browser: Chrome 131.0.6778.205

[netlify]

✅ Deploy Preview for ohif-dev canceled.

Name	Link
🔨 Latest commit	c616d1c
🔍 Latest deploy log	https://app.netlify.com/sites/ohif-dev/deploys/67a06c3ae4e69a00083a04ee

[netlify]

✅ Deploy Preview for ohif-platform-docs ready!

Name	Link
🔨 Latest commit	c616d1c
🔍 Latest deploy log	https://app.netlify.com/sites/ohif-platform-docs/deploys/67a06c3a0cdfe2000879775a
😎 Deploy Preview	https://deploy-preview-4634--ohif-platform-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[sedghi]

we are reworking the customizationService so stay tuned until it is done

[abhijith-trenser]

we are reworking the customizationService so stay tuned until it is done

Thank you for the information, @sedghi. Would you happen to have a feature branch or work item that could serve as a reference for the implementation?

[sedghi]

Can you rebase on top of the new customization service and follow what's done there please? Sorry for the inconvenience

[abhijith-trenser]

Can you rebase on top of the new customization service and follow what's done there please? Sorry for the inconvenience

@sedghi I have updated the branch based on the latest changes in the customization service. Would you mind reviewing it when you have a moment?

[sedghi]

See my comments thanks

[sedghi]

I really appreciate the PR, which is pretty much in line with our goal of making each component customizable.

I'm not entirely sold on the CustomizableRenderComponent idea, though. You're basically replacing the entire component logic with a customized version, and I'm not sure that's the right approach. This could have some pretty significant side effects - for instance, what if certain parts of the app want to use the default version, while others want to use a customized ContextMenu?

I think a better way to handle this is to consider customization as an all-or-nothing proposition outside of the platform/ui and platform/ui-next. I'm not a fan of calling the customization service directly from our platform/ui and ui-next, as that means services logic is leaking into the UI. I know some components are already doing this, but I'm in the process of cleaning them up. In my opinion, there shouldn't be any mention of services, commands, or managers in the platform/ui and ui-next.

I'd rather see more instances of customizationService.getCustomization('ui.contextMenuItem') than injecting the customization service at the component level. That way, we can keep the customization logic separate from the UI components. Does that make sense?

CCing @wayfarer3130 for his opinion

[abhijith-trenser]

Thanks, don't forget to bun install , try upgrading bun as well to 1.2

@sedghi I have executed the tests after the Bun installation, and everything is working perfectly.

[sedghi]

Thanks a lot, this is great