Enhance KeyboardShortcuts component to automatically document 3rd party shortcuts in modal

[dsifford]

This discussion began in a thread on Slack, so I've copied that conversation below...

dsifford [Today at 4:02 PM]
Random question for the maintainers: Has there ever been any talk about adding the ability for plugin authors to hook into the "keyboard shortcuts" modal to allow them to also list the shortcuts they added in the same place? Seems like it would be a fairly simple addition just by adding in a slot/fill..

aduth [3 hours ago]
I’ve not seen it be discussed. It sounds like a good idea, though I’m not sure adding a Slot and letting it be a free-for-all would be my preferred way to go about it. I could see it being a nice enhancement to the KeyboardShortcuts component. In other words, if you use the component, you get this behavior “for free”. Also has the added advantage of making it impossible for a plugin’s keyboard shortcuts not to be listed, and centralizing behavior to this component can open up some options around mitigating conflicts of shortcuts between plugins and with native key combinations.

Happy to discuss this further and work together to figure out a proper solution. I think @aduth has exactly the right idea though.

[talldan]

I followed up on the slack convo (https://wordpress.slack.com/archives/C02QB2JS7/p1556222525488500 — signup required), so also duplicating that over here:

I worked on the modal. I did think about it at the time. However, I agree with @aduth, that registering shortcuts should add them to the modal, and also potentially open them up for customisation (#3218)

The challenge with the KeyboardShortcuts component is that it’s a slave to rendering logic (the shortcut is only bound when the component is rendered), so the shortcuts wouldn’t be registered all at once. That side of things might require a rethink.

An API that registers the shortcuts along with the descriptions into a store might be one way to go. The KeyboardShortcuts component could then access the registered shortcuts from the store using a selector.

[karmatosed]

I am removing the 'User Experience (UX)' label as part of a label cleanup. It's not being used anymore consistently so let's try and keep to 'needs design' and 'needs design feedback'. If we find a need for another label we can consider it but having those 2 should cover this.

[phpbits]

Additional Slot is needed in my honest opinion. As of now I'm using registerPlugin to create my own menu for Markdown keyboard shortcuts. If there's an available option to just hook this to existing Keyboard Shortcuts, I'll just add them there. I've created #15880 as separate issue with this concern of mine. Thanks!

[enriquesanchez]

This was discussed during today's Gutenberg design triage meeting in Slack.

The team agrees that having this functionality would be beneficial. We think it'll be a good idea to start simple, and allow plugin authors to register their shortcuts and have them appear below the default list of shortcuts in the modal.

If we later find the list gets too long, we can look at implementing an accordion UI or something similar for better organization.

One concern that was raised was the potential for conflicts with default shortcuts. We think that for now, we should look at implementing checks to avoid this.