Clarify the meaning of Node Position (possible inconsistencty with TipTap)

[marczi]

We are trying to navigate up and down in the document hierarchy using ResolvedPos and sometimes the results are very confusing.

We create a small sample code, that uses three custom nodes: a taskList that can have multiple taskItems. Each taskItem has a header (taskItemHeader) which is a NodeView and a paragraph that holds the content of the taskItem

• Is it correct to say that a ResolvedPos at a pos “P” represents the parent node at absolute position “P”?
• Is it correct to say that p.posAtIndex(0, p.depth) will return “P”? (this can be seen in the demo with orange text, click the Show getPos button and check “parent ResolvedPos depth”)

We also experienced discrepancies with TipTap (if we assume correctly, this is a TipTap bug and we will report it):

Node Positions – Tiptap

When iterating children at a given NodePos (position “P”), TipTap returns positions that are different by 1 compared to what can extract from ProseMirror’s ResolvedPos.

Demo app: https://qmypw3.csb.app/ https://codesandbox.io/p/sandbox/tiptap-getpos-qmypw3?file=%2Fsrc%2FApp.tsx

Thanks for any explanation in advance!

[marijn]

@marczi

Is it correct to say that a ResolvedPos at a pos “P” represents the parent node at absolute position “P”?

I don’t know what that means.

@marczi

Is it correct to say that p.posAtIndex(0, p.depth) will return “P”? (this can be seen in the demo with orange text, click the Show getPos button and check “parent ResolvedPos depth”)

No, not at all. posAtIndex with 0 as the index gives you the position at the start of the parent node that position falls into (should be equivalent to .start).

[marczi]

Dear Marijn, thanks for the quick response

@marijn

@marczi

Is it correct to say that a ResolvedPos at a pos “P” represents the parent node at absolute position “P”?

I don’t know what that means.

Sorry that this question was confusing. Let’s say I have a taskItemHeader node (which is actually a NodeView and this is the child of a taskItem) at position 43. I call doc.resolve(43). In this case, will it represent the parent node, which is the taskItem?

@marijn

No, not at all. posAtIndex with 0 as the index gives you the position at the start of the parent node that position falls into (should be equivalent to .start).

Hm, I guess I still miss something So if I call doc.nodeAt(43), then I get taskItemHeader, that is clear Then I call

const resolvedPos = doc.resolve(43);
const depth = resolvedPos.depth;
console.log(resolvedPos.node(depth), resolvedPos.posAtIndex(0, depth);

It will return taskItem which is the parent, still OK.

But posAtIndex will return 43, which is the start position of the taskItemHeader, not the taskItem (actually this is the same value I get from getPos() in the NodeView for taskItemHeader)

[marczi]

In other words, if I have a taskItem that starts at 42 and it has a child taskItemHeader that start at pos 43, then how do i find out the absolute position of the taskItem?

[marijn]

@marczi

In this case, will it represent the parent node, which is the taskItem?

If you resolve the position before a node, you’ll get a resolved position in its parent node (with nodeAfter pointing at the node that the position is before).

You seem to be confused by the fact that nodes are identified by the position in front of them, but resolving that position and taking .node(depth) will give you the node around that position. Use doc.nodeAt(pos) if you want to find the node after that position.

[marczi]

Thanks, i tried to understand, but it is getting clear now