lzb.constructor.post-change
Action fired while the block builder watches the save state of the block post. Hook it to push data of your own to the server at the moment the block itself is saved.
Attributes
| Name | Type | Description |
|---|---|---|
data | Object | isSavingPost, isAutosavingPost, shouldUpdate, blockData, postId |
| Name | Type | Description |
|---|---|---|
isSavingPost | Boolean | the editor is saving right now |
isAutosavingPost | Boolean | the save in flight is an autosave |
shouldUpdate | Boolean | a save that was not an autosave has just finished |
blockData | Object | current block settings, with slug, icon, category and controls |
postId | Number | ID of the lazyblocks post being edited |
The action sits in a useEffect keyed on isSavingPost, isAutosavingPost, postId and blockData, so it runs on every change of any of them and not only on save. Typing one character into a control label fires it. shouldUpdate is the only argument that marks a finished save, and it is true exactly once per save that was not an autosave.
It fires immediately after the builder issues its own /lazy-blocks/v1/update-block-data/ request, not after that request resolves. A handler that reads the block back over REST can still see the previous values.
Usage
let myDataChanged = false;
wp.hooks.addAction(
"lzb.constructor.post-change",
"my.custom.namespace",
function ({ shouldUpdate, postId }) {
if (!shouldUpdate || !myDataChanged) {
return;
}
wp.apiFetch({
path: "/my-plugin/v1/block-saved/",
method: "POST",
data: { post_id: postId },
}).then(() => {
myDataChanged = false;
});
},
);Without the shouldUpdate gate the handler runs on every keystroke in the builder, which is how a request per character ends up in the network tab. Pro uses exactly this shape to write its block collections once the block post is saved.