Changing the save function without deprecation

[NayzR]

I understand the importance of deprecation when the blocks are used somewhere. However when I am still in the development phase, is there a way to revert/delete the old save function without the hassle deprecating the block, since the block is not used anywhere?

[NayzR]

Nevermind, you can just recover the block in the site editor, which will reset the save function

[stokesman]

For development it may be helpful to make and include a script that creates and inserts your blocks as you'd like to test them. That way markup changes won’t require you to recover the blocks. With regards to that, in the config of registerBlockType it accepts an example property which is nice for block previews if your block is expected to have style variations. That same property can be accessed by the dev script and used as the basis for creating the blocks for testing.

[NayzR]

@stokesman Thanks for the answer and sorry for the late response. Currently I still just recover the block, but since I use tailwind it gets tedious to do this for every little change. Also I can not make it a static block since I need JS for the logic. Can you explain me how a script like this look like? And I looked into the example property but it seems to me useful when you want to test different attribute values or am I wrong? Thanks in advance.

[stokesman]

Hi @NayzR, I think pehaps the best explanation is a working example.

Script to insert test blocks into particular posts

( ( {
	blocks: { createBlock, createBlocksFromInnerBlocksTemplate, store: blocksStore },
	blockEditor: { store: blockEditorStore },
	data: { dispatch, select },
} ) => {
	// A list of post ids in which block insertion is applied.
	const applicablePosts = [ '2' ];
	const blockToInsert = 'core/cover';
	const overlayColors = [ 'peachpuff', 'skyblue' ];

	const createBlockWithInnerBlocks = ( blockName, attributes, innerBlocks ) => createBlock(
			blockName,
			attributes,
			createBlocksFromInnerBlocksTemplate( innerBlocks )
		);

	// Waiting for window load seems suffcient for all blocks to have been registered.
	// It’s possible though that a custom block registers itself later than this and in
	// such a case subscribing to the blocks store instead of using the load event would
	// allow waiting for it before proceeding with the insertion routine. Even if the
	// block to insert isn’t a late registrant requiring the subscription, using one can
	// have a minor benefit in case the page to insert blocks on already has lots of media
	// present as the subscriber will likely trigger the block insertion sooner.
	window.addEventListener( 'load', () => {
		const locationParams = new URLSearchParams( window.location.search );
		// Bails unless the post id is included in the applicable ones.
		if ( ! applicablePosts.includes( locationParams.get( 'post' ) ) ) {
			return;
		}

		const { getBlockType } = select( blocksStore );
		const { getBlocks } = select( blockEditorStore );
		const { insertBlocks, replaceBlocks } = dispatch( blockEditorStore );
		const { example: { attributes, innerBlocks } } = getBlockType( blockToInsert );
		const blocks = [
			createBlockWithInnerBlocks( blockToInsert, attributes, innerBlocks ),
		];
		// Creates additional blocks to test some attribute variations.
		for ( const customOverlayColor of overlayColors ) {
			blocks.push( createBlockWithInnerBlocks(
				blockToInsert,
				{ ...attributes, customOverlayColor },
				innerBlocks
			) );
		}
		const currentBlocks = getBlocks();
		if ( currentBlocks.length ) {
			replaceBlocks(
				currentBlocks.map( ( { clientId } ) => clientId ),
				blocks
			);
			return;
		}
		insertBlocks( blocks );
	} );
} )( wp );

Some notes:

• This demos the idea with the Cover block but you’d just replace blockToInsert with the name of your block.
• The script is meant to be enqueued by your block’s plugin (probably conditionally on some development flag) or by a separate plugin as that can be simpler. If you wish to quickly demo it, then comment out the line where the load event listener is added and the line with its matching parenthesis and closing bracket. Then it can be pasted into the dev console with a post open in the post editor.
• It won’t insert blocks unless the post id is in the applicablePosts list and that’s meant for you to customize. I put in that condition because inserting blocks on any post could be a nuisance in case you’re doing other stuff on that install. It’s easy to remove the condition and have it work on all posts.
• It does not work in the Site editor on pages. It could work there but probably needs some sort of detection of what template part is available to insert the blocks into.
• It replaces all the existing blocks in the post if there are any. That’s because if you are testing how your block’s save function works it’s probably desirable to clear out the old blocks on the next refresh (since they’re likely to be marked invalid). It’s easy to change that of course.
• It expects that the block to insert is registered with an example property. That’s really not necessary as the same data could just be coded into the script. Whatever seems best in your context.