Gutenberg: Gutenberg + React frontend

[espenjanson]

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

I am trying to use the Gutenberg editor with a React-based frontend and in order to be able to render interactive Gutenberg blocks, I need to save their data as a JSON-object somewhere in my database (right now I have created a meta value called blocks on every post). I post all of the blocks that are currently in the editor's redux store ( subscribe( () => /* some conditional logic */ store.getBlocks() ) ) each time a post has been saved and then grab that JSON in my frontend application, rendering React components based on the attributes and block names. However, some of the core blocks save HTML in their "content"-attribute, which breaks the JSON (and my frontend site).

Describe the solution you'd like

Keep HTML-attributes separated from raw attribute data. If the core block is an inline image, I just want the image src and the information that it is an inline image (block name should suffice). On some blocks, there is an attribute called originalContent. Perhaps the solution could be that HTML is stored in an HTMLContent attribute, or a new attribute on each block called "rawAttributes" where everything is stored as primaries.

Another solution would be to have a REST-endpoint called "block-data" where all block-data could be fetched (again, only data, no HTML markup).

[espenjanson]

I fixed my issue (I think) by stringifying twice and thereby escaping the double quotes inside the HTML tags. However, I still think this is an extremely relevant feature to for all of us doing headless WP. Without some simpler way to extract block data, most will probably skip Gutenberg and keep on doing ACF + headless setup, which is sad since Gutenberg + headless could be amazing!

[dnusca]

This might help you out - https://github.com/royboy789/gutenberg-object-plugin

[espenjanson]

Thanks, saw that plug. But it seems like an awful lot of code in order to achieve what I want to achieve? I don't need a new database table for my blocks, I just want to save them as a JSON-object to post meta. Code I am using right now is less than 50 lines and does the job (although my stringify(stringify()) solution feels a bit hacky. There must be some point at which all (new) blocks contain no HTML-values, only attributes, and I therefore think there should be a function that writes that clean data as a JSON to some place in the database, that is triggered on save.

[jmikrut]

I would also like to know this as right now we use ACF with custom fields and their Flexible Content field type to accomplish this very thing. It works well, but Gutenberg has a nicer interface and we would like to move over from our reliance on the Classic Editor to being able to properly parse information within Gutenberg using React.

I've also seen the plugin but I believe this should be accomplished with a query parameter on all REST routes to potentially replace the rendered content with something like blocks. I don't want content duplicated in responses as our frontends will _never_ need the rendered content.

[designsimply]

I don't know how to answer your question directly about saving block data as a JSON object in the database in order to setup a headless WP, but I do know that there is currently an experiment underway to try to load the block editor without a dependency to a post object in https://github.com/WordPress/gutenberg/pull/13088 and it sounds very similar to me. I was wondering if the discussion there is relevant to your efforts?

[youknowriad]

Hi there!

@designsimply is right in suggesting the block editor module for third party usage of Gutenberg https://developer.wordpress.org/block-editor/packages/packages-block-editor/

When it comes to the data storage of Gutenberg itself, that's something that was discussed heavily in the past and it's very unlikely that it's changing in the near future.

Also, returning blocks as JSON data in the response of the posts endpoint is something we're considering for the future but there's still some intermediary steps required before achieving that. the first one is the server-side definition of the block types that is being worked on. #13693