Add the abillity to remove apiFetch middlewares

[mauricewijnia]

Is your feature request related to a problem? Please describe. When using Gutenberg outside of the WordPress environment some of the apiFetch middlewares can cause unexpected behaviour.

Describe the solution you'd like I'd like to be able to disable the apiFetch middlewares as I see fit.

Describe alternatives you've considered Right now I'm removing the middlewares from the Gutenberg code before building the Gutenberg packages that I'll use in my project.

[youknowriad]

Thanks for opening the issue. Would you mind share more details:

• What kind of context you're using Gutenberg in? Why are you using the editor package instead of block-editor? I guess you're just replacing the API?

• What are the middlewares causing trouble and why?

Thanks.

[mauricewijnia]

I'm developing a Gutenberg package for Laravel projects called Laraberg. Which is similar to Drupal's Gutenberg implementation.

I'm using a custom fetch handler to send and receive data to either an API or from static data source. The main part that is causing issue's is the fetchAllMiddleware, when this is enabled any request for reusable blocks are not being processed correctly and the reusable blocks do not show up. But since none of the middlewares are not of any use for Laraberg, I'd prefer to disable them all.

Right now I disable the middlewares in the Gutenberg source code before building the packages. The advantages of being able to remove the middlewares during runtime in my opinion are that it's a lot cleaner for my project, but it's also something that could be useful for similar projects (e.g. Gutenberg for Drupal).

Thanks for the quick reply!

[youknowriad]

That middleware is very WP specific indeed. An alternative/simpler solution could be to just move the addition of this middleware to an inline script when registering the WordPress script. Thoughts?

cc @kadamwhite

[mauricewijnia]

Moving all WP middleware to WordPress does feel like a cleaner solution. Not sure if I could help out with a PR over there though.

[kadamwhite]

Moving more and more to inline scripts feels a bit brittle, but I'd be conceptually in favor of having a WP customizations script file that we could include in the core-distributed version/built or just load contextually that would do additional re-wiring to add the WordPress specifics.

[youknowriad]

@kadamwhite Makes me wonder if we need something like add_inline_script (after) but using a script file.

[kadamwhite]

That’s an interesting idea... I actually think I’d have used that myself last week if it existed for a different problem, so I’m provisionally in favor!

[senadir]

Revisiting this as I also need to remove a core middleware userLocaleMiddleware because it doesn't apply to our use case in frontend.