Design Proposal: Extensible Dropdown Service

[ek68794998]

Goal

To allow the dropdown menus in the designer to have host-specific menu items.

Proposal: Overview

Today, there are two different types of dropdown menu: 1) the user right-clicks a node ([1], [2], [3]), or 2) the user clicks a (+) button in the designer ([1]). As these are built into the designer with a predefined set of available actions, hosts implementing the LAUX designer are not capable of adding their own actions to these dropdowns.

Being proposed here is the implementation of a new service that can be implemented at the host level, which provides a list of menu configurations (represented by a flexible interface allowing customization of the item) and render them as menu items. Both options are discussed at a technical level in the section below.

For dropdowns specifically, there would be some limitations in place:

1. Top-level menu elements must appear as standard menu items using the Fluent 9 <MenuItem> standard control. A callback must be attached.
2. Top-level menu elements may provide a submenu of items.
3. Submenu items may be one of two things: a Fluent 9 <MenuItem>, or a custom control provided via render callback.

Proposal: Technical design

A new service, perhaps IDesignerUiInteractionsService, would be introduced. This service would provide the following approximate interface:

interface DropdownMenuCustomNode {
  renderCustomComponent: () => React.ReactNode;
}

interface DropdownMenuItem {
  ariaLabel?: string;
  icon?: string | JSX.Element;
  onSelect: () => void;
  text: string;
}

type DropdownMenuOption = DropdownMenuItem | DropdownMenuCustomNode;

interface TopLevelDropdownMenuItem extends DropdownMenuItem {
  priority?: number;
  subMenuItems?: DropdownMenuOption[];
}

interface IDesignerUiInteractionsService {
  getAddButtonDropdownMenuItems?: (parentNodeData: NodeData | undefined, childNodeData: NodeData | undefined) => TopLevelDropdownMenuItem[];
  getNodeDropdownMenuItems?: (nodeData: NodeData) => TopLevelDropdownMenuItem[];
}

A host service could then implement the interface; for example, something like a "lock action" feature would work like this:

class UiInteractionsService implements IDesignerUiInteractionsService {
  public getNodeDropdownMenuItems = (nodeData) => {
    return [
      nodeData.isLocked
        ? { icon: <UnlockIcon />, onClick: () => { /* ... */ }, text: 'Unlock action' },
        : { icon: <LockIcon />, onClick: () => { /* ... */ }, text: 'Lock action' },
    ];
  };
}

Another example may be an action to add a note to the workflow:

class UiInteractionsService implements IDesignerUiInteractionsService {
  public getAddButtonDropdownMenuItems = (_parentNodeData, _childNodeData) => {
    return [
      { icon: <EditIcon />, onClick: () => { /* ... */ }, text: 'Add note here' },
    ];
  };
}

These would then get rendered as additional actions in the dropdown menu:

Use of a custom renderer would look something like this:

class UiInteractionsService implements IDesignerUiInteractionsService {
  public getAddButtonDropdownMenuItems = (_parentNodeData, _childNodeData) => {
    return [
      {
        icon: <EditIcon />,
        onClick: () => { /* Do nothing */ },
        subMenuItems: [
          { renderCustomComponent: () => <div style={{ /* ... */ }}>Here are all your favorited items!</div> },
          ...(favorites.map((favorite) => (
            { icon: <FaveIcon />, onClick: () => { /* Do nothing */ }, text: favorite.displayName },
          )))
        ],
        text: 'Add favorited action',
      }
    ];
  };
}

Which would produce this type of menu:

The only remaining implementation would be in the files called out in the lead of this proposal, to convert the provided DropdownMenuOption items into <MenuItem> and submenu <Menu> components in the node & dropdown files ([1], [2], [3], [4]). The work for this is not strictly defined here as it is not of high technical complexity.

With the above in place, existing menus would be converted to DropdownMenuOption objects so that they could be generically defined the same way as the new custom ones. Something like this:

As shown in the snippet diff above, one additional implementation detail is that the priority field could be used on top-level menu items to sort the actions as desired. Default actions would have their own priorities assigned (for example, "Delete" = 1000, "Copy action" = 2000, "Pin action" = 3000), and then a priority value of 2500 would go between the copy & pin menu items.

Callouts

1. This service should be extensible so that, in the future, more UI interactions can be added if desired. For example, adding menu items to the panel header dropdown (the one that today has "Add note" and "Delete"), or adding more buttons to something like the connections panel. It would really allow hosts to be extensible in areas that matter to them.
2. This service would not override the built-in options such as "Add action", "Copy action", etc.

[rllyy97]

I think this is great! Everything looks great, just a few notes below:

• UiInteractionService is great
• getAddButtonDropdownMenuItems we should just name getAddButtonMenuItems
• getNodeDropdownMenuItems we should name getNodeContextMenuItems
• I think the priority idea is smart
• We should also allow fluent dividers somehow (I guess we could just render as a custom component, but if we can build it in that would be better)

My only other conern would be that if we have the onClick callbacks in the service files, I'm not sure how accessible it will be to interact with data from hooks / redux actions. This might not be an issue for your usecase though.

[ek68794998]

• getAddButtonDropdownMenuItems we should just name getAddButtonMenuItems
• getNodeDropdownMenuItems we should name getNodeContextMenuItems

Yup, sounds good.

• I think the priority idea is smart
• We should also allow fluent dividers somehow (I guess we could just render as a custom component, but if we can build it in that would be better)

I think maybe something like showDividerAbove?: boolean is a good idea? I was thinking of adding sections, but I think that would cause issues with the priority system, so to reduce complexity perhaps just a flag is good enough. Thoughts?

My only other conern would be that if we have the onClick callbacks in the service files, I'm not sure how accessible it will be to interact with data from hooks / redux actions. This might not be an issue for your usecase though.

It should be able to work as long as the functions are exported. Do you have any thoughts on specific issues, or a better way to do this overall?