What problem does this address?
When a block is set to be hidden, the scripts and styles enqueued by this block will still be loaded.
What is your proposed solution?
Currently the plugin uses the render_block filter to conditionally hide blocks: it returns an empty string if the block should not be visible or the block's html if no visibility tests fail. But if the block enqueues a custom script (i.e. by using the viewScript param in block.json), this script will still be loaded as only the block's html is stripped.
When using the pre_render_block filter instead, all further processing of the block (including enqueuing of scripts) can be short-circuited by returning anything else than null.
A downside of this approach would be that it's not possible to append any custom classes to the block's html this way, if it should not be complety stripped (like you do at the moment). Maybe this part must still happen in the render_block callback.
What problem does this address?
When a block is set to be hidden, the scripts and styles enqueued by this block will still be loaded.
What is your proposed solution?
Currently the plugin uses the render_block filter to conditionally hide blocks: it returns an empty string if the block should not be visible or the block's html if no visibility tests fail. But if the block enqueues a custom script (i.e. by using the viewScript param in block.json), this script will still be loaded as only the block's html is stripped.
When using the pre_render_block filter instead, all further processing of the block (including enqueuing of scripts) can be short-circuited by returning anything else than null.
A downside of this approach would be that it's not possible to append any custom classes to the block's html this way, if it should not be complety stripped (like you do at the moment). Maybe this part must still happen in the render_block callback.