Skip to content

Block API: Introduce abstraction for better management of inspector controls  #62439

Open

Description

What problem does this address?

Currently, inspector controls are created inside of a block's Edit component. This means that any modification to those controls must also be done in each block's Edit component on a case-by-case basis, and it is difficult to introduce generic changes that affect a large number of block controls in a robust manner.

But, what if we were to devise a way to introduce a wrapper around each of these inspector controls, allowing us to more easily customize their behavior or appearance?

This impacts at least two potential enhancements:

  1. Allow for site builders and admins to granularly control which inspector controls appear or not in the editor based on their use case, which would allow for end users to have a more customized, tailored experience with less cognitive overload
  2. With Block Bindings, introduce logic to indicate whether attributes are connected or not in a single location rather than needing to create custom logic inside every Edit component (related issue: Block Bindings: Add indicator that an attribute is connected instead of hiding the controls #61406)

What is your proposed solution?

@ellatrix has already done an early exploration here: #60779

The idea is to move inspector controls to be an attribute of block settings, then render each control separately inside a wrapper, which, as mentioned above, could pave the way for toggling their display on or off, as well as creating robust logic for indicating whether a particular attribute is bound.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions