Additional actions in the Comment Thread

[marrej]

based on discussion in #156885 this issue proposes extension defined additional actions for Comment Threads. (See image below for reference).

Motivation

To improve the efficiency of work in Code Reviews, extensions providing CommentThreads would like to add direct resolution of Comments without the need to open the Reply button area (Done in the image).
Additionally, there may be extra actions that may be attached to comment, such as proposed edit that can be applied, which conceptually belong together with the Comment, but at the moment do not have a discoverable area to be placed in. (At the moment actions connected to the whole CommentThread could be either placed in the title to be directly visible, relying on icon to be discovered, or in the reply area which is concealed by the additional click)

Technical proposal

To allow extensions to define additionalActions which are always visible in the CommentThread, a new area should be defined, right under the commentReply (Reply Button Area at the bottom of the CommentThread).
This area would contain separator & extension defined actions.
Extensions can define both single commands and submenus.

Submenus will be rendered as Dropdown buttons, where the first action in the submenu will be treated as the primary action - due to the submenus not carrying Command.
If submenu contains only 1 action, then a single button will be created instead of dropdown button.
In case of no action attached to submenu, the submenu action would be displayed.

NOTE: if there are doubts about AdditionalActions being the correct name for this new area, we should change it.

[alexr00]

@daviddossett what do you think of this proposal? The idea is to have a place in a comment thread for actions that aren't well represented by icons.

[daviddossett]

If I'm understanding correctly, this is more about just enabling extensions to contribute generic buttons below the input. It sounds like you can just add as many as you want, with some having secondary actions?

Some other thoughts off the top of my head:

• We should consider if the "Add comment" button should be the only primary button in this view. I'm concerned have more than one in close proximity. See GH example below.
• @alexr00 would this mean we could move the "Resolve conversation" button to the additional actions row?

[alexr00]

@daviddossett yes, we'd be able to move the "Resolve" button to be always visible. One other thing that came out of discussion on this: If we have these buttons, should be move the "Reply" button/input to be one of these buttons instead of it's own custom button? It currently looks like an input, but if we have this row of buttons then it might make sense to remove the reply input/button and instead have it be an "additional actions" button.

[daviddossett]

My gut reaction is that keeping both the input and the resolve button visible before interacting would be useful:

Showing the input (today it's technically a button but let's say we made it a real textarea component) makes it feel more inviting to click on and start typing vs a button IMO. It also has the benefit of tracking the experience on github.com more closely.

[albertelo]

If I'm understanding correctly, this is more about just enabling extensions to contribute generic buttons below the input. It sounds like you can just add as many as you want, with some having secondary actions?

To clarify from our end: we would only have one primary action, if we add more actions they would all be secondary. This means one primary action in the whole component, so no multiple primary actions per row

[alexr00]

We reviewed the UX for the split button yesterday, and after discussing we've decided to not allow the split button right now. We try to keep the split button as a way to show one action with multiple variations. For that reason, we don't want the split button to be an overflow button. Some examples:

The mock up in #156885 (comment) shows a split button with several disjoint actions. We can't come up with a good use case for the split button with our primary first party consumer of the comments widget, GitHub Pull Requests and Issues, and I'm not aware of another extension that would really benefit from the split button.

We don't want to encourage extension authors to break our paradigm of how a split button should work, which is why, for now at least, we're not going to allow the split button in the comments additional actions.

I'd be happy to hear arguments for why we should support the split button! I expect that this will be an ongoing discussion.

[alexr00]

I've also added a limit of 4 buttons to the additional actions. This is similar to what we do with other menus where we allow up to 4, and then when that is exceeded we move actions 4 and up into an overflow menu. Since we haven't defined what an overflow menu means for a row of buttons, the number of buttons is truncated at 4.