Hi all,
While looking into something else in architect-html, I noticed we depend on a fork of react-contexify :
"@origam/react-contexify": "github:origam/origam-react-contexify#v6.0.1-origam.0"
The fork was introduced in July to carry a submenu positioning fix - long submenus in the model tree (the New and Actions menus) ran off the bottom of the screen, so the fork clamps their vertical position into the viewport. That was the right call at the time, but it’s worth revisiting for two reasons.
First, upstream react-contexify is effectively dead: npm still shows 6.0.0, last published 2022-11-13. There is nowhere to send the fix, and no upstream fixes are coming to us either - including anything React 19 related. So the fork isn’t a temporary state, it’s permanent maintenance we’ve taken on.
Second, the positioning problem the fork solves is one that current libraries handle out of the box. Anything built on Floating UI does collision detection natively, so the patch we’re carrying would simply become unnecessary rather than needing to be ported.
Off the top of my head, @radix-ui/react-context-menu looks like the obvious candidate - it’s at 2.3.7, published a couple of weeks ago, supports React 19, and its ContextMenu.Trigger covers our usage directly (all our call sites are plain right-click handlers). Base UI would be the other one worth weighing, though it’s still at 1.0.0-rc. I’d want to compare properly rather than pick by reputation.
The scope looks contained: the dependency is used only in architect-html, across four files - ModelTree.tsx, TabHeader.tsx, DesignSurface.tsx and TabControl.tsx - and frontend-html and chat-html don’t use it at all. The main real work is restyling, since the modern options are unstyled.
A useful side effect: because it’s a github: dependency, Yarn has to clone the fork and run a full install and build of it during preparation, which drags in its dev dependencies (including Cypress and its binary download) on every cold install and CI run. Moving to a registry package removes that entirely.
I’d be glad to evaluate the options properly and carry out the swap, if that sounds worthwhile. Before I start, is there any reason the fork was preferred over a replacement, or any constraint on adding a new UI dependency to the Architect that I should know about?
Thanks!