Handling dynamic blocks in Faust

[calebsmithdev]

I'm currently reading through the docs and looking for suggestions/recommendations on the best approach here as we look at converting an ACF Block driven site over to NextJS. Ideally - I'd like to break away from using ACF blocks so we aren't supporting both PHP and React written components. For some some blocks, there are some pros/cons with having different HTML rendered content editors, but largely our blocks are simple enough that they can load just fine in the editor.

We've had enough of our blocks change over the years that I'd rather stay with Dynamic Blocks so we aren't having to attempt recovery frequently when we make changes. I'm not sure if that is the best approach, but it seemed like a bigger pain when we are dealing with nearly 100 page websites.

All of that said - Does Faust have a way to use the new blockSet approach with Dynamic Blocks? If not, does anyone have any recommendations how to render React components in the editor and still keep them in the NextJS project? The blockset command has been awesome so far in my testing, but the whole Gutenberg save() setup really complicates a few things for me when we look at future changes to our sites.

[theodesp]

Hey @calebsmithdev . Regarding the new blockSet command my understanding is that you can make a component dynamic by returning a null Save function.

When you use the registerFaustBlock function you can optionally pass a Save Function here

registerFaustBlock(Block, {metadata, saveFn: () => null})

On the other hand in the WordPress side you need to provide a renderCallback function when registering a dynamic block.

In our plugin we do use the register_block_type function in this section of the code:

I suppose we could allow for a custom filter to run so that users can include their own renderCallbacks maybe something like:

$block_args = apply_filters( 'faustwp_get_block_args', $block_args, $block_metadata );

// provide a render_callback for that particular block making it dynamic
if ( $block_metadata['name'] == 'create-block/block-a' ) {
  $block_args['render_callback'] = function () {...}
}

Does it make sense? It that what you are looking for?

[calebsmithdev]

That makes sense! So I did a more thorough test of the saveFn and editFn yesterday and it pieced together on that front. I did not try to pass in null for the saveFn, but I'll give that a shot next. Since I have the blocks setup in Nextjs already, does it matter if the saveFn has anything in it, since the frontend will override the HTML that is outputted and replaced with the attributes from GraphQL? Or am I really oversimplifying it? 😅

I think I could get by with adding simple placeholder HTML to the saveFN, as long as that doesn't disrupt the editor HTML as a whole and cause that "Attempt Recovery" message. It didn't seem like that was too much of a problem when I was changing up the editFn, but I didn't test out adding/removing attributes and how that would affect it.

[theodesp]

I think the save function is sensitive to changes and if you change attributes or the structure of the saved html, then the existing saved blocks. will have this "Attempt Recovery" message. This would be not the case with Dynamic Blocks since they are rendered on demand.

[calebsmithdev]

Very helpful. Thank you so much for the insights!

[theodesp]

#1762