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

On Mobile Gutenberg, we will always have the problem of blocks that are unsupported.
We are working on a solution that will allow the user edit those blocks without leaving the mobile app, using a web view that loads and editor instance from their site.

Ideally we want this web editor instance to just show the single block the user wants to edit, Together with controls to edit this single block, hiding any other control like Page edition, Saving/Publishing, inserting new blocks, etc...

We have a working solution that looks like this:

What we do is basically:

• We load the wp-admin's new-postURL.
• We use window.wp.data.dispatch/select to insert/retrieve the HTML content of the block.
• We use injected CSS to hide the unwanted UI elements.

Insert Block script
Retrieve Block script
Injected CSS

But there are a few issues with this approach:

• The time of when is safe to inject the block varies on WPCom and a Self-Hosed site.
  • On WPCom, just waiting for window.onload is not enough.
• We can't hide all the elements we would like to hide using just CSS.
• We will have troubles if there are changes on CSS classes or if there are bigger structural changes, making this approach quite fragile.

Describe the solution you'd like

The objective of this ticket is to gather ideas for possible solutions to implement on a future version.

This is my innocent solution I would like to see, but you are the masters:

• It would be great to have a "Single Block" mode, which will not render any element that's not needed for editing a single block. This could be set via a LocalStorage setting or a URL Query (or maybe other).
• Since window.onload won't work in all cases, maybe we could have an window.wp.editorReady or something similar to know exactly when it's safe to inject the block.
• Other ways to inject/retrieve the block? My fear it that the current action/selector might get deprecated at some point.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

• I tried hiding the elements using JS, but it's not easy to find the elements since most of them doesn't have IDs.
• I've tried using window.wp.data.subscribe to inject the block when the store starts receiving events but this also didn't work. (apparently it's still too early).
• My first approach to inject the block timely was to wait for a specific element in the editor (edit-post-header) to appear in the document. This worked on WPCom but seemed to be way too fragile.