Filter to extend BlockList component

[swissspidy]

Is your feature request related to a problem? Please describe.

For a project, I need to customize the editing screen in order to display blocks horizontally with some additional UI controls, i.e. as a slider/carousel.

This is a bit challenging, because Gutenberg is made for editing text in a vertical fashion.

While it is possible right now to add some custom elements in the editor screen by creating some elements on the fly and using wp.element.render, there is no way to modify the BlockList component that is used by VisualEditor.

There's currently a filter for the individual BlockListBlock elements used within BlockList, but not for the whole rendered block list.

Describe the solution you'd like
If there'd be a filter or some other way to extend the block list, that would come in very handy.

Describe alternatives you've considered

The only two options right now are either overriding the Gutenberg component and completely replacing the window._wpLoadBlockEditor part in edit-form-blocks.php, or creating elements on the fly to achieve the desired result (additional elements around the block list).

Open for suggestions if there are alternatives.

Related: #14009, #6072

[chrisvanpatten]

I have a case which I think is related, where I want to display a visual placeholder between certain blocks, based on index/position (e.g. to indicate automatic ad placements in a post). I believe being able to filter the BlockList would enable that possibility.

[simison]

Related to #26494 ?

[ellatrix]

Could you elaborate on the use case? What would the filtered block list look like? I'm very hesitant to introduce now component filters. It could be that we can also do this with a props filter instead.

[CodeProKid]

I also have a use case that requires this functionality. I need to wrap all of the blocks that get rendered in the blocklist with a few shared providers for things like data fetching and setting up shared context for components to leverage.

We have an existing front-end component library that we want to integrate within the editor but don't want to have to change the architecture of the library to work with the constraints of the editor.

Here's what our implementation currently looks like to get this working in a standalone instance of the editor:

<Provider store={store}>
  <SharedContextProvider>
    <ApolloProvider client={apolloClient}>
      <SharedComponentProvider client={componentProviderClient}>
        <BlockList />
      </SharedComponentProvider>
    </ApolloProvider>
  </SharedContextProvider>
</Provider>

This works in our custom standalone instance, but there is no way (as far as I can tell) to implement something similar when we go to integrate our components into WP's instance of the editor.

[nachos5]

I am trying to use react-query with the editor but it's really impossible without this feature since I can't wrap the editor/BlockList. I can create a container block utilizing inner blocks which wraps them with a react-query provider but it would be so much better to not be forced to rely on a block in every page/post for this functionality.