We've introduced a new concept to Perspective Components: a first-party context menu.
This context menu is configured within the props of each component, within meta.contextMenu. Each component's context menu is disabled by default, and may be enabled by setting the meta.contextMenu.enabled property. Each item (aside from Separator) also allows for configuring an icon to be displayed.
There are five types of items supported as of today:
Link
Message
Method
Separator
Submenu
Link:
Allows for users to specify a link which will be navigated to when a user clicks this item. To specify Perspective project pages, provide the exact configured URL for that page, complete with the leading slash (/someUrl/myPage).
Message:
Allows for calling of configured Message Handlers, including specification of a scope. The payload to be sent may be configured as part of this item object.
Method:
Invokes a custom method of the component on which this context menu lives. You may configure arguments to be passed into this custom method with the params object. Please note that the keys entered here must match the exact kwargs specified in the custom method - though order within the param object does not matter; we do not support "positional" arguments via this route.
Separator:
A general separator to keep categories of your context menu separate. This item only honors styling available to the <hr> HTML element. Please review these docs for more information.
Submenu:
These items contain their own child items which again consist of the same available item types. Hovering over one of these items will result in a submenu appearing next to the current context menu or submenu.
Excellent! Haven't installed a nightly build yet, but this is definitely a feature worth it.
I'll just mention in case the right person sees this but - these context menus as far as I know won't work on IOS for the reasons described by this post
As mentioned in that thread, mobile devices make use of the long-press event to trigger contextual menus, but that then causes a clash between which Event we would use to trigger this in general as we don't want the long-press Event to result in a context menu for desktop users. Additionally, we would need to change how the submenus work when it comes to mobile devices because mobile devices don't have a true concept of "hover".
All this to say that it's not impossible this could ever come to mobile devices - we could provide context menu functions just like we've done for the tooltip functionality, and we could make sure that submenus of context menus expand when users click on a submenu item - but this feature is not supported for mobile devices at this time.
Unknown. At this time the ticket itself is to discern how we will do it - and does not define how we will do it. I did recommend a function of that name when the card was made, but there's no guarantee it will be the adopted approach.
Very exciting. I am trying to implement this, but having issues with Method. It works in Designer but in both Workstation and Browsers, I keep getting the error in the gateway log that the method does not exist. I just wrote a simple method called 'hello' with no parameters. The method just writes 'hello' to the console.
But when triggered from workstation, safari, chrome (on both windows and mac laptops) with page refresh, project updates...etc. It doesn't write to the console and I get the following error.
Fair question. But yes, absolutely. Changes to the menu were coming through as I saved. I started off with a more complex method and then started cutting it back 'hello'.
Interesting. I wasn't able to replicate in 8.1.25, but I WAS able to replicate in 8.1.26. We've opened a ticket to fix it as part of 8.1.26 but the root cause hasn't been made clear to me yet. What's also interesting is that (at least for me) custom methods put in place before 8.1.26 continue to work as expected.
I'm discovering that my previously configured onContextMenu events are no longer executing in 8.1.25. Is there any configuration changes required to make the new feature work in conjunction with existing onContextMenu events?
No, previous onContextMenu events should not be impacted, and we have testing in place to make sure that the onContextMenu Event is still "fired" when a Context Menu is in place, regardless of the enabled state of the Context Menu. Could you provide some more insight into the previously-existing events (what they did) and also the Context Menu settings you have in place for the component in question?
