component(ContextMenuViewport): move to ui-next with theme support#6008
component(ContextMenuViewport): move to ui-next with theme support#6008dan-rukas wants to merge 4 commits into
Conversation
✅ Deploy Preview for ohif-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| defaultPosition?: { x: number; y: number }; | ||
| [key: string]: unknown; |
There was a problem hiding this comment.
defaultPosition is declared in the interface but never read in the component body. Since the dialog service handles positioning externally via uiDialogService.show({ defaultPosition }), this prop will never be forwarded to the component as a prop, making the declaration dead code.
| defaultPosition?: { x: number; y: number }; | |
| [key: string]: unknown; | |
| [key: string]: unknown; |
Prompt To Fix With AI
This is a comment left during a code review.
Path: platform/ui-next/src/components/ContextMenuViewport/ContextMenuViewport.tsx
Line: 11-12
Comment:
`defaultPosition` is declared in the interface but never read in the component body. Since the dialog service handles positioning externally via `uiDialogService.show({ defaultPosition })`, this prop will never be forwarded to the component as a prop, making the declaration dead code.
```suggestion
[key: string]: unknown;
```
How can I resolve this? If you propose a fix, please make it concise.There was a problem hiding this comment.
I think @greptileai is correct here. Please update.
There was a problem hiding this comment.
Agreed — here's the fix. Just drop the defaultPosition line; the index signature already handles any extra props passed through:
| defaultPosition?: { x: number; y: number }; | |
| [key: string]: unknown; | |
| [key: string]: unknown; |
That removes the dead declaration while keeping the interface flexible for anything else the dialog service might forward.
| if (!items) { | ||
| return null; | ||
| } |
There was a problem hiding this comment.
The guard if (!items) returns null only when items is undefined or null. If ContextMenuItemsBuilder.getMenuItems returns [], the controller's own if (!items) return also passes through, and the component renders an empty container div — a small invisible-but-present box at the calculated position. Adding || items.length === 0 to the guard would prevent this; note the old component has the same behavior so this is not a regression introduced by this PR.
Prompt To Fix With AI
This is a comment left during a code review.
Path: platform/ui-next/src/components/ContextMenuViewport/ContextMenuViewport.tsx
Line: 16-18
Comment:
**Empty array bypasses the early-return guard**
The guard `if (!items)` returns `null` only when `items` is `undefined` or `null`. If `ContextMenuItemsBuilder.getMenuItems` returns `[]`, the controller's own `if (!items) return` also passes through, and the component renders an empty container div — a small invisible-but-present box at the calculated position. Adding `|| items.length === 0` to the guard would prevent this; note the old component has the same behavior so this is not a regression introduced by this PR.
How can I resolve this? If you propose a fix, please make it concise.There was a problem hiding this comment.
Since it is not a regression let's leave it.
|
@claude review |
jbocce
left a comment
jbocce
left a comment
There was a problem hiding this comment.
Thanks for this. One small comment.
2 participants
Context
Moves the viewport context menu from
@ohif/uito@ohif/ui-nextasContextMenuViewport. The legacy component used hardcoded colors that don't respond to theming. The new component uses ui-next token-based styling and includes minor UX improvements.Changes & Results
ContextMenuViewportto@ohif/ui-next— same props API as the legacy component, now with theme-aware styling and UX polishcontextMenuUICustomization.tsto import from@ohif/ui-nextTesting
Checklist
PR
semantic-release format and guidelines.
Suggested PR title:
feat(ui-next): add ContextMenuViewport component with theme supportCode
etc.)
Public Documentation Updates
additions or removals.
Tested Environment
Greptile Summary
Migrates the viewport context menu from
@ohif/ui(ContextMenu) to@ohif/ui-next(ContextMenuViewport), replacing hardcoded color classes with Tailwind token-based theming and adding a subtle open animation. The props contract and item-action wiring are preserved, so existing controller and menu-item builder code works without changes.ContextMenuViewportis functionally equivalent to the old component;item.action(item, props)still has access toonClose,onShowSubMenu, andonDefaultvia the...propsspread, so menu close-on-click and submenu navigation continue to work.cursor-default select-nonereplacescursor-pointeron interactive items — this matches shadcn/ui conventions but removes the pointer-cursor affordance users typically expect from clickable menu rows.defaultPositionis declared in the TypeScript interface but is never read by the component (positioning is managed externally by the dialog service).Confidence Score: 4/5
Safe to merge; the migration is behaviorally equivalent and all observations are minor style and polish items.
The component faithfully mirrors the old ContextMenu's prop wiring and close-on-click behavior. The only tangible change worth a second look is the switch from
cursor-pointertocursor-defaulton menu items, which removes a standard interactive affordance without a clear design reason.ContextMenuViewport.tsx — the cursor class and unused interface prop are both worth a quick look before merge.
Important Files Changed
cursor-defaultinstead ofcursor-pointeron interactive items and declares an unuseddefaultPositionprop in the interface.@ohif/uiContextMenu to@ohif/ui-nextContextMenuViewport; straightforward and correct.Prompt To Fix All With AI
Reviews (1): Last reviewed commit: "Refine styling" | Re-trigger Greptile