Sending blocks to WordPress?

[scripting]

As more people at Automattic try WordLand I'm hearing a question, always politely asked, why aren't we using blocks?

There's no religious issue here, if it were easy to do, I would be ready to try it soon, to see what happens, if anything in WordLand breaks. On an experimental basis.

My first thought though, is why the addPost API on the WP side of it, doesn't do the translation. If I specify the content_type of the content as html, the server could parse that into a block structure.

In any case I wanted to open a place to explore this from an architecture standpoint. If there has to be an HTML parser somewhere that generates block, I would think it should be as central as possible, so everyone doesn't have to write the same tedious code. It's the kind of thing imho you want to bury as deeply as you can.

[jeherve]

That's a good question.

It's probably worth mentioning that this isn't really necessary. WordLand already works well with the block editor. Yes, it publishes HTML, but the block editor displays HTML just fine. If folks want to transform that HTML into blocks later on, for example if they want to edit a published post in the block editor, they can use the built-in "Convert to blocks" feature that will convert that HTML content into blocks.

That said, we could still consider having WordLand publish blocks in the first place. I can think of 2 main ways to address this:

1. There could be a middleware, on the WordPress.com REST API side of things, that would convert HTML sent to the API and add the HTML comments expected by the block editor to render blocks in the block editor. I don't know if that's something that we can reasonably accomplish. That middleware would have to support a wide variety of HTML that would potentially be sent to the API by different applications (like WordLand), so it's likely it wouldn't be able to convert all types of content that it receives.
2. The initial editor (WordLand) could send the HTML with the expected markup to the API.

I think there are potentially different ways to approach that second option.

Right now, WordLand relies on a Medium.com WYSIWYG editor clone to manage input. Instead, it could rely on the WordPress block editor itself. Here is a useful resource on how one can build a custom editor on top of @wordpress packages: Building a custom block editor

There are a few examples of the block editor in the wild already:

• Isolated block editor: Repackages Gutenberg's editor playground as a full-featured multi-instance editor that does not require WordPress
• Drupal offers an option to use the Gutenberg editor in Drupal admin.

This would, however, completely change the current editing experience in WordLand. That's not something you may want to do.

Alternatively, you could parse the HTML in WordLand without changing the editing experience, and attempt to convert that HTML to block markup using rawHandler and serialize, from the @wordpress/blocks package:
https://www.npmjs.com/package/@wordpress/blocks

You would then send the output to the WordPress.com REST API as you do today.

[scripting]

@jeherve -- Thanks as always for the super thoughtful response!

WordLand already works well with the block editor.

I was concerned this might be a problem, and if it was, I wanted to get in front of it.

So this is something I won't worry about.

My main drive right now is doing something special with WordLand and RSS.