Introduction of Block Inspector Tabs Extension

[theaminuli]

Issue Description:

As discussed in the blog post Introduction of Block Inspector Tabs, the introduction of Block Inspector Tabs offers enhanced flexibility and organization for inspecting and managing blocks within the WordPress editor. However, it would be beneficial to explore ways to extend the functionality of Inspector Tabs to cater to diverse user needs and accommodate various block types and customizations.

Objective:

The objective of this GitHub issue is to brainstorm and discuss potential methods and strategies for extending Inspector Tabs within the WordPress block editor. By allowing for the extension of Inspector Tabs, we aim to empower developers and users to customize and enhance their editing experience further.

Proposed Solution:

To extend Inspector Tabs functionality in Gutenberg, several strategies can be considered:

API Enhancement: Improve the Inspector Tabs API to offer hooks and filters that enable developers to register custom tabs, define their content dynamically, and manage their behavior effectively.

Custom Tab Registration: Implement mechanisms for registering custom tabs through Gutenberg blocks, plugins, or themes, allowing developers to tailor the inspector interface to specific block types or editing contexts.

Flexible Tab Content: Provide flexibility in defining the content of custom tabs, allowing developers to include various controls, settings, or information relevant to the block being inspected, such as block attributes, styles, or metadata.

Tab Visibility Control: Introduce options for controlling the visibility of tabs based on factors such as block type, user roles, or editing mode, ensuring a personalized and intuitive editing experience.

[Lovor01]

I want to present my need for custom tab in block sidebar. I am developing a slider block based on Swiper.js and aim to make it highly flexible. To achieve this, I want to allow users to add custom Swiper configurations via a JSON input. Since these configurations can be quite elaborate and require a potentially long JSON string, I provide a textarea control for this input.

Placing this control in a separate custom tab within the block sidebar would greatly enhance the user experience. If the control were included in an existing tab, such as the block settings or styles tab, users might need to scroll extensively to find and edit the JSON input, especially in blocks with many options. Additionally, the block settings tab is already quite populated, and adding this feature there would increase clutter.

A dedicated custom tab offers a clean, organized, and user-friendly approach, making it easier for users to manage and edit their Swiper configuration.

I think block hooks (defined in @wordpress/hooks) are used very sparsely, compared to PHP hooks. PHP hooks are very good and popular solution for extensibility so I would expect that block hooks would be used more in the code. Perhaps performance is reason why they are not?