Using InnerBlocks with post meta storage

[mboynes]

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

I attempted to build a custom block which uses the InnerBlocks component and which stores its content to post meta. I could not find a straightforward way to do this; it appears that InnerBlocks will always save to post content.

Describe the solution you'd like

From my perspective, one high-level approach would be that the InnerBlocks component would allow for an onChange prop, or similar, which would allow a custom block to easily call setAttributes() to store InnerBlocks.Content. There would also need to be a way to pass InnerBlocks the contents/value from attributes.

[noel-schenk]

@chrisvanpatten and @jorgefilipecosta #7785 #7247 #11271 #6751

[designsimply]

Does #6751 (comment) help you? Or is it different because it's a save function and not an onChange?

[mboynes]

Does #6751 (comment) help you? Or is it different because it's a save function and not an onChange?

Hey @designsimply, unfortunately that doesn't help, at least as best I can tell.

[designsimply]

Okay! Sorry it didn't. We'll want to wait for input from someone who's a bit more knowledgeable than I am on the subject. 😊

[youknowriad]

I think you should be using the block editor module directly to perform this (build an editor inside an editor). We have some documentation here. https://wordpress.org/gutenberg/handbook/designers-developers/developers/packages/packages-block-editor/

With this package you pass a list of blocks as an array and retrieve and array. You can decide to serialize/parse the blocks using wp.blocks.parse/serialize but it's on you to save these anywhere you like.

(this package will only be available in WordPress 5.2).

[mboynes]

The block editor module looks very interesting, and I look forward to getting my feet wet with it! I see a lot of potential. And while I agree that it provides a roundabout solution to this problem, I don't agree that it resolves this issue. From a developer's experience perspective, that seems like a fairly complicated abstraction. To summarize why that is,

1. If I want to create a custom block that stores to post meta, that's supported out of the box and is very simple to do.
2. If I want to create a custom block that uses InnerBlocks to provide a block editing environment within my block, that's supported out of the box and is very simple to do.

However, if I want to merge (1) and (2) and have a custom block that provides a block editing environment saving to post meta, now I have to write a significant amount of code and jump through some fairly complex hoops (especially as it pertains to no registered block types, from the sounds of it). As a developer trying to build complex interfaces in Gutenberg, this is a relatively common scenario for me, and I would expect it to be roughly no additional work.

[youknowriad]

Sorry for the late response.

The Block editor already provides a high number of APIs, and adding APIs is not always a good solution because of the fact that for each added API, we need to maintain it forever, so adding APIs is a very deliberate decision.

You can also take a look at the reusable block's implementation https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/block/edit.js#L134-L143 which does exactly what I proposed above.

I don't think it's too much code, or complex code to be honest and I don't feel like it's a very common scenario for all block editor users.

[pascalknecht]

@youknowriad I personally don't feel like that is an additional API. InnerBlocks are a core concept as well as the meta source. Hence, in my opinion, these two should work together. I've also just encountered this problem myself.

[clfleury]

@youknowriad This is something I just encountered as well. While it's not impossible to utilize the extra implementation as you said, I'm questioning the logic of just not including this in core. You said yourself it's not much or complex code; that negates the point that this would be a fully-fledged API that is difficult to maintain.

[skysarwer]

Can we re-open this issue? I completely disagree @youknowriad that " [It's not] a very common scenario for all block editor users."

Being able to add content before and after the main content area (like what the native Title block does in the editor) is super important for making the gutenberg experience well rounded.

There are so many applications to this that I can think of, that are currently bottlenecks in transitioning to Gutenberg.

[skysarwer]

@mboynes Seeing as you were asking this around 3 years ago, I am curious if you arrived at any solutions for this? Thank you!