I hope there can be a callback when a certain type of node is removed/added into a doc

shi-yan · February 15, 2023, 4:40pm

Right now, I can do this using the

dispatchTransaction callback, but for adding, I need to scan all the steps’ fragments to find out the node types. For deleting, I will see no fragments, then I will have to scan the document to discover the removed nodes.
use a customized node view, since a nodeview has a constructor and a destroy function. But I have to implement the content-updating behavior myself.

I think adding this callback is useful when we want to count or manage nodes globally. Two usecases I have in mind:

auto label equaitions/pics with a number and update them automatically as new equations and images are inserted. We can also refer to them in text using Fig 2. or Eq 3. The references can be updated automatically also.

an automatic content table. As I create new heading blocks, I also generate a small content table for quick navigation.

marijn · February 15, 2023, 5:05pm

This is something you’ll have to do yourself based on the information in the transaction. The way the editor works it just sees a new document, and there’s no concept of individual nodes being added or removed.

ssaric · February 22, 2023, 4:52pm

I believe I can chip in. I had a similar requirement recently, but dropped it due to some other factors.

I found this:

gist.github.com

https://gist.github.com/BrianHung/3b5f9b2fe97a353150324a19250a5257

changedDescendants.ts

/**
 * Helper for iterating through the nodes in a document that changed compared 
 * to the given previous document. Useful for avoiding duplicate work on each transaction.
 * Source: https://github.com/ProseMirror/prosemirror-tables/blob/master/src/fixtables.js
 */
import type { Node as PMNode } from "prosemirror-model"

export function changedDescendants(old: PMNode, cur: PMNode, offset: number, f: (node: PMNode, pos: number) => void) {
  let oldSize = old.childCount, curSize = cur.childCount
  outer: for (let i = 0, j = 0; i < curSize; i++) {

This file has been truncated. show original

readme.md

The general idea is that you keep your decorations in a plugin state field, and have your decorations method just read it from there, rather than rebuild it on every transaction. The field’s apply method maps the old decoration set when there are any changes, and updates the regions touched by the transaction’s steps (which you can get by iterating over their step maps, as found in tr.mapping).

https://discuss.prosemirror.net/t/decorations-performance/2381/4

What you do is track the position of the element you are interested in, and on each transaction, map to its new position (possibly tracking both the start and end so that it’s easier to determine whether any of the step maps in the transaction touch it).

https://discuss.prosemirror.net/t/how-to-update-multiple-inline-decorations-on-node-change/1493

You don’t need to use filterTransaction – you can simply react to transactions as they are dispatched. To see the extent of the document ‘touched’ by a given transaction, you can call forEach on each step map in its mapping property, but doing this is kind of subtle as each step will have its positions expressed relative to the document as it was when that step was applied, and later steps might move those positions again.

This file has been truncated. show original

This basically can give you all the nodes that changed during the transaction. The trick is to identify what you need.

For example: if you change a text in a paragraph, that paragraph will be detected as changed, but so will all his parents. This will require some tweaking.

Hope it helps!