Unknown block proof of concept

[etoledom]

I've been playing around with displaying unknown/unsupported blocks from an html source and I made it work. This is no more than a proof of concept and is quite badly coded, so I'm not sending a PR just yet. 😆

All my next statements are based on what I "think" and have learned so far, but of course they can be completely wrong, please help me with that!

Expected behavior

• When converting from HTML to blocks, we want to show a special block UI for Gutenberg blocks that are not registered in the mobile version.

By inspecting the web version, the freeform block is used for unknown types (setUnknownTypeHandlerName( freeform.name );), being freeform the classic editor.

This handle raw html or anything that is not a registered Gutenberg block.

Based on that, we could rethink the expected behavior in this way:

• If the html section is not a Gutenberg block (aka "raw html") we want to show it on an Aztec based block (our version of "classic editor").
• If the html section is a Gutenberg block, but is not registered, we want to show a special block UI for it (as before).

To achieve this, we can follow this steps:

1. Port the Freeform block from web into mobile, as an Aztec based block (just like the paragraph block).
2. Register the Freeform block with setUnknownTypeHandlerName.
   1. At this point, it should display any not-registered block and raw html in the Aztec block. (From Parse html into known blocks #100)
3. Detect if a Freeform block will display content that "seems to be" a Gutenberg block, and show the "unknown" UI instead.

In this way we don't need to register a new Unknown block (at least not yet), and we follow closely how the web version is implemented.

For the first and second steps requite sending a PR to gutenberg. Since the second step is really simple, I'd send both together.

The last step feels a bit "hacky", but it's quite a simple way to get the expected behavior without loosing the block data, and easily converting from html to blocks and vice versa.

Q: Why not to use the paragraph block instead of declaring a new Aztec based block?
A: Because it mess up the real paragraph blocks, making the system think that they are unknown.

Q: How did you declared the Freeform block?
A: It was a copy-paste from paragraph/edit.native.js to freeform/edit.native.js. I'm sure there's a better way 😆

This is how it looks when parsing raw html (it is represented as a freeform block)

This is loading and unknown Gutenberg block, it shows a custom UI.

[hypest]

I've been playing around with displaying unknown/unsupported blocks from an html source and I made it work

Looking good @etoledom 🎉

The only thing I'm "tripping" over is the FreeForm block, which I think it's something that needs to be implemented web-side and we just port it over, along with the "unknown type handling" functionality.

[etoledom]

@hypest , the Freeform block is already implemented in the web, it translates to Classic editor block.

What I did was just to port it to mobile.

Unless I misunderstood you? 🙄

[hypest]

(I named it Freeform as in web)

I understood that as a sign of creating a new block type, instead of nativizing (that's what I refer to as porting, sorry if it wasn't clear) an already implemented one on the web.

[etoledom]

Right, sorry! I see how that can be confusing.

I just edited that part of the text to avoid confusion in futures references :)

1. Port the Freeform block from web into mobile, as an Aztec based block (just like the paragraph block).

[hypest]

My impression is that this ticket/exploration is not relevant anymore but, can you confirm @etoledom? We can close it if so.

[etoledom]

Yes, most of this is already outdated. Still we would need to set the freeform content handler to handle raw html at some point. 👍