onChange fires for indentation, but when you call getChanges, the array of changes is empty

[niieani]

Describe the bug

editor.onChange(...) event fires for indentation, but when you call context.getChanges(), the array of changes is empty.

To Reproduce

1. open this simple reproduction
2. create two blocks
3. open the devtools console
4. try to indent the 2nd block

You'll see the an empty array of changes, which is something I didn't expect.

Same problem applies when dragging & dropping a block to rearrange its position.

Context

I was prototyping and playing around with BlockNote to see its capabilities, and was hoping it would be possible to create a sync system using the onChange hook (to autosave the blocks in a DB).
I know I can also access the underlying ProseMirror transactions, but I was under the impression onChange would be the better level of abstraction, as it is aware of block IDs. Let me know if I'm approaching this wrong.

Looks like maybe the function here:

BlockNote/packages/core/src/api/nodeUtil.ts

Line 158 in 95a72b7

export function getBlocksChangedByTransaction<

doesn't support indentation or block move changes?

Misc

• Node version: N/A
• Package manager: N/A
• Browser: Chromium 137.0.7151.69
• I'm a sponsor and would appreciate if you could look into this sooner than later 💖

[nperez0111]

getChanges should report indenting & dedenting a block, if it does not do that, it is a bug.

But, for what you describe, using it as a sync system for storing the document into the DB, it is not sufficient. getChanges will tell you only what blocks have been added/removed/updated, what you should be storing is the entire document at once. So, you can use something like onChange: () => { storeSomewhere(editor.document) } which will have the entire blocknote document as json

[niieani]

@nperez0111 thanks, glad to hear it's a legitimate bug.

As far as onChange - I can't use it because I don't want to store the document in its entirety. In my system, there is no concept of a document - only a view (which contains a list of blocks) - everything is a block, and each block is stored independently. A view can contain a list of blocks, which are then composed into a BlockNote document dynamically. Block's children can be either folded and unfolded, which fetches the data for a the children blocks asynchronously (adds a pending/spinner block) and once fetched, replaces it with block with actual text.

I'm also considering storing transactions for each block, instead of serialized block state, which is another reason why it would be great to have per-block transactions.

[nperez0111]

I really believe that you should reconsider your architecture. An editor can only edit content which it has full control over. For example when pasting external content it can be possible that an ID is rewritten even though it was the same content.

If you are assembling each block into a view, I don't see why you wouldn't just store that entire state at a time.