Consider a generic API for programatically navigating interfaces

[talldan]

What problem does this address?

TLDR - it's too difficult to implement a button or a shortcut that opens up another specific part of the editor interface.

Long version:
A common requirement in our editors (and really all applications) is a user action that opens up a specific part of the interface. Some examples:

• Clicking the an icon button or using a shortcut to open a specific sidebar (e.g. List View, Block Library, Global Styles)
• Deep linking to a specific part of the interface when loading the editor (e.g. a past example was opening up Global Styles from the WordPress about page, it was very buggy. A future example could be going straight into edit mode instead of browse mode)
• Opening and focusing a specific inspector tool (e.g. Clicking a block toolbar button to open up the Navigation Block's inspector List View, or Opening an inspector tab)

At the moment the code to do this isn't always easy to write. It often involves:

• Using a number of different APIs that are very inconsistent
• Working around package dependencies (a block can't easily call an API defined in the edit-post or edit-site packages).

This means a poor developer experience for many contributors, code with high bug-potential, and also the potential for bad practices like introducing incorrect dependencies.

What is your proposed solution?

TLDR - lets do something about it, what are some options? Below I present one.

Long version:
I think it's worth discussing the qualities such an API should have, my thoughts are:

• It should be the bottom of the dependency chain rather than the top), and so usable everywhere (it should be like wordpress/components rather than like wordpress/edit-post).
• It shouldn't be complicated to use. For example, it should be possible to open a specific tab AND open the sidebar that tab is within using one function call. The caller doesn't know about the implementation details.
• It should be open to future requirements, like use of the browser history API, application routing, deep linking.
• It should reflect the optional and decoupled nature of our code. Not every block editor needs to implement List View or even the Block Inspector, so it should be possible to detect whether that feature is implemented and can be navigated to. This would make it possible to optionally render a button that opens List View or the Block Inspector based on the feature existence.
• It should support accessibility best practices, like transferring focus to the right place (but not necessarily implement this).

Based on that, the best thing I can think of is a signals style API, somewhat similar to the keyboard shortcuts API.

• Particular parts of the UI are registered on initialization as signal receivers.
• A button or shortcut can send a generic signal.
• Another part of the UI (e.g. a sidebar or collapsible panel) can listen to and receive a signal and perform the necessary action. It would be possible to wrap existing APIs with such a listener, so that everything doesn't have to be rewritten.

This kind of API isn't without problems, but I still think it could be an improvement over what Gutenberg has now.

Thoughts? What are some other options?

(cc @WordPress/gutenberg-core)

[draganescu]

Yes! At this moment we have a hotch potch of prefferences and settings that we read from various state places. It's always confusing to decide in which store to save UI related stuff and not all the stuff is in @wordpress/interface.

While working on distraction free mode and recently on #46907 I've needed to make the UI behave differently based on one general toggle or situation and it was both times more complicated than expected. Also as #46907 shows the lack of such an API is an invitation to worse ideas :)

[talldan]

I'm wondering now whether commands (those used by the command center) might be the best way to do this, as they share the same set of concerns (focus management, history management, they're groupings of actions).

I guess the only change is that we would be able to call commands programatically, and not just from the command center UI, and that might have implications.