Widget context menu button extension api deprecated?

And a related question that I think you could include in the extension point guidelines: Where's the best place to put tools for editing the selected widget? A widget context menu button would be limited to one specific action (but there are already other posts that request more possibilities), the bottom bar is a bit limited and hard to notice, and a side panel or modal is a bit intrusive/tedious to open and close all the time. I suppose the answer heavily depends on specifics, though.

@Mikal H Henriksen  ... cc’ing @Farbod Saraf 

I think we had to track down the API team last summer on this question and got an answer that lead us to the below code.

Note that in our context it was designed as a widget context menu access point to a sidebar plugin. This gets called as miro.board.ui.openLeftSidebar('builder.html'). 

Also note that our code below is setting up toolbar extension point also…   You’ll focus on the bottom half … on the section: getWidgetMenuItems: () => {…} 
It sounds like in your case you’d like the onclick to just run a function - easy enough → put that in the ‘onClick’  value (‘function assignment’ -- not sure what to call it in this context.) onClick: __<your function here>__

Here’s an image of the below sample index.js file in action.
 Hope this helps. Let me know if you hit a snag.

miro.onReady(run)

const icon24 = '<YOUR SVG HERE>'



function run() {
  miro.initialize({
    extensionPoints: {
      toolbar: {
        title: 'Perception-Map-Demo',
        toolbarSvgIcon: icon24,
        librarySvgIcon: icon24,
        onClick: async () => {
          const authorized = await miro.isAuthorized();
          if (authorized) {
            miro.board.ui.openLeftSidebar('builder.html', { title: 'Perception-Map-Demo' })
            console.log(window.location.host)
          } else {
            miro.board.ui.openModal('not-authorized.html')
              .then(res => {
                if (res === 'success') {
                  miro.board.ui.openLeftSidebar('builder.html', { title: 'Perception-Map-Demo' })
                }
              });
          }
        }
      },

      getWidgetMenuItems: () => {
        return Promise.resolve({
          tooltip: "Perception-Map-Demo",
          svgIcon: icon24,
          onClick: async (widgets) => {
            const authorized = await miro.isAuthorized();
            if (authorized) {
              miro.board.ui.openLeftSidebar('builder.html')
            } else {
              miro.board.ui.openModal('not-authorized.html')
                .then(res => {
                  if (res === 'success') {
                    miro.board.ui.openLeftSidebar('builder.html')
                  }
                });
            }
          }
        })
      }
    }
  })
}

Thank you, @Max Harper, that's helpful and will for sure save me some time! Although I was more asking about the "why" and "if" rather than the "how" which you've answered, so I'm still holding out for an official answer on that.

Also, thanks for making Clusterizer, it impressed and inspired me enough to actually try making my own plugin! 

Hey, no, who marked that as an answer? I don’t want that, I don’t have the answer yet, and I can’t take it off again myself :/ Read a bit more closely, please.

@Mikal H Henriksen   I sincerely apologize … My thumb accidentally hit the wrong button on the mobile screen … was trying to just ‘thumbs up’ your last comment… but I hit the ‘mark as best answer’ which is a checkmark that sits right next to it.   I tried everything to undo it, but It looks like that’s not an option - like its irreversible from my user-type (weird)…  I reached out to a community admin @Marina to help us unmark as ‘best-answered’ until you get a satisfactory answer.  (I’m deputized to be able to mark “Best Answer” … but I totally messed it up here -- #fired.  :(   

@Farbod Saraf Is listening to the developer community as they encounter issues with the API/SDK and related documentation, I hope he might be able to help with this issue.  
 

@Mikal H Henriksen -- Excited you’re venturing into developing Miro apps. Happy to help any time with any other questions you encounter, just PM me and I’ll lend a hand. 

Oh, no worries, you're forgiven 😁

And now it's fixed! Thanks, mods! 

Thanks @farbodsaraf that's precisely what I needed to know (and feel validated for being right about my suspicion 😇). Take your time, get it right. I'm happy with using the side panel for now. 

Please, please, please, reconsider sunsetting the context menu API. This is by far the most intuitive interface for end users for interactions that revolve around an individual widget or a group of widgets.

P.s. In case User Experience consistency is the concern you might want to consider UX guidelines that indicate for which types of interactions the context menu may be used and perhaps even constrain the types of iconography allowed.

@Marijn Huizendveld i agree. It’s a very useful interface point.  
 

Actually the way it is now, developers can run logic at the point of receiving the current widget selection and from there they can by themselves create what you’re talking about… a restriction of the appearance of their apps icon(s), based on various cases: e.g, there’s a card in the selection, something in the selection has metadata from our app, there’s have more than one item, there’s exactly one frame, etc.  

Thanks for entertaining this conversation Max :-)
To ensure I understand what you’re saying: do you mean that this is now also possible by listening to SELECTION_UPDATED or do you mean that you like the deprecated status quo provided by getWidgetMenuItems?

In my case I’d like to show a context menu item that allows people to transform a sticky note to another type of widget. The transformations allowed depend on the selection as well as adjacent connected sticky notes. This could be put in a sidebar but the barrier to start using the feature would be too high. People feel they’re faster manually if it’s so “far away” in the UI.

@Marijn Huizendveld 
I bring that up as to say… I think its a strong feature of the way they designed it before deprecating it. It would be great to have … 
I think they may be encouraging this usecase to be handled on ‘toolbar’ or ‘bottom bar’… but I’m with you, I think it would be nice to have a solution for presenting your tools in the widget context menu - without bogging it down with way too many icons.  

getWidgetMenuItems 

Here’s an example where I only show my app icon if … well in this case it was dumb test… but ‘if the first widget in the selection is a sticky note.’  I think this was a fast hack to only work on a single sticky.  

Ignore the auth code… its old

The point here is… the widgets in the argument of the arrow function that is the callback function set as the ‘value’ to the getWidgetMenuItems ‘key’ in the object set to ‘extensionPoints:’ in ‘miro.initialize()’  are the current selected widgets… so that callback function can take the widgets in the selection at the time of every selection, and run logic on them before displaying options for the user… see below the result of the code below, where if I select a line I don’t see “PM” or “Perception Map Demo”, but if I select a sticky, I do see “PM”...

With a ~single sticky note selection:

With not a ~single sticky note selection: e.g. line selected : 
 

I’m intending to do something similar. In my case I’m filtering down the selection to the desired type (e.g. Cards), and then do something to all of them.

In an ideal world Miro would not only revert the deprecation, but also offer an API to have expandable context menus like they have for Sticky Note size and colors. One can dream ;-)