onDelete, onRemove or onRemoveBlocks event handler

[coxato]

Is your feature request related to a problem? Please describe.
I would like to have a specific event handler when a block or blocks are deleted, because I have some linked blocks that are being added as pairs, e.g (startBlock and endBlock) so if I delete a startBlock the endBlock is automatically deleted, because they are "pairs" in my implementation.
So I don't want to do that validation on the onChange method every time.

Describe the solution you'd like
Having a onDelete or onRemove or onContentDeleted or onRemoveBlocks event, so it receives a callback with the deleted blocks[] as argument.
something like this:

  const editor = useCreateBlockNote();

  useEffect(() => {
    if(editor){
      // a function to know when blocks are deleted so we don't use onChange every time  
      editor.onRemoveBlocks((deletedBlocksArray) => {
        myCustomHandler(deletedBlocksArray);
      })
    }
  }, [editor]);

Describe alternatives you've considered
Right now I do a validation for ALL the blocks on every onChange, but I think isn't the best approach, I would like to do those validations only when a block is deleted, if we are editing or creating/adding blocks I don't need to do extra validations.

is there any other possible solution?

[nperez0111]

This is related to an issue we are tracking: #1566

[coxato]

This is related to an issue we are tracking: #1566

oh, very nice. I will keep an eye out for any news.

[Tim-Pet]

Hi there, this is an awesome feat! Are there any plans to expose block specific changes on a block level as well (so the change logic could get handled inside custom blocks)?

e.g.:
block.onChange(e => e.preventDefault(); window.alert("All links to this block have been deleted successfully"))

[nperez0111]

@Tim-Pet I don't completely understand what you are trying to achieve with this.

But, it does not make sense to expose this sort of API within a custom block, because the change is derived from what already happened, so the custom block's instance will just have been destroyed (or at least about to), so it wouldn't really be able to do anything about it.

[Tim-Pet]

Ah fair point, thanks for pointing me in the right direction.

@Tim-Pet I don't completely understand what you are trying to achieve with this.

In the end I want to prevent certain blocks from deletion or apply custom behavior for an improved UX for complex custom blocks

But, it does not make sense to expose this sort of API within a custom block, because the change is derived from what already happened, so the custom block's instance will just have been destroyed (or at least about to), so it wouldn't really be able to do anything about it.

Yeah that totally makes sense to me. thanks for jumping in on that. Appreciated

[nperez0111]

In the end I want to prevent certain blocks from deletion or apply custom behavior for an improved UX for complex custom blocks

Ah, clearer use-case, that, I can help you with. Here is an implementation of that (using the primitive that this change API is built on top of):

import { BlockNoteView } from "@blocknote/mantine";
import { useCreateBlockNote } from "@blocknote/react";
import { getBlocksChangedByTransaction } from "@blocknote/core";
import { Plugin, PluginKey } from "prosemirror-state";

// instantiate a prosemirror plugin which will filter out transactions which meet some criteria
const MyFilterExtension = {
  plugin: new Plugin({
    filterTransaction: (transaction) => {
      const blocksChanged = getBlocksChangedByTransaction(transaction);
      console.log(blocksChanged);
      if (JSON.stringify(blocksChanged).includes("NOPE")) {
        return false;
      }
      return true;
    },
    key: new PluginKey("my-extension"),
  }),
};

export default function App() {
  const editor = useCreateBlockNote({
    _extensions: {
      filterExtension: MyFilterExtension,
    },
  });

  return <BlockNoteView editor={editor} />;
}

This will reject any transaction that contains the text "NOPE" in it (just to show that you can arbitrarily reject transactions). You can see it working in this video:

Screen.Recording.2025-05-02.at.12.53.11.mp4

Maybe we could add something like this in the future, not sure what that API would look like though

[Tim-Pet]

thank you so much, this is amazing!

[nperez0111]

Closing as done with #1585