Different parsing strategy for large documents

1

We’d like to support very large documents (500+ pages) in our application. Therefore we thought it would be a good solution to only parse/render the nodes which are currently displayed in the viewport (plus some nodes before and after for a smoother scrolling experience).

The view should then react to each scrollUp() and scrollDown() event and update its content. A similar behaviuor can be found in androids RecyclerView or some infinite scroll libraries. The document content should still be editable although only a part of the document is displayed.

We thought of solving this by implementing a custom DOMSerializer or creating the EditorState with just a part of the document, but none of these seem promising.

As far as I understand CodeMirror supports exactly this. Perhaps there is an approach for this already implemented or in planning for ProseMirror?

How would you tackle this problem?

2

Nope, this is considered out of scope for ProseMirror. I don’t have a strategy for this, and I am not planning to incur all the complexity that this entails in the core library. Some users have gotten good results from structuring their interface so that each chapter has its own ProseMirror instance. You can use offset maps to map changes from such sub-editors into a larger document.

2 Likes
3

Hello!

Is this still out of scope of Prosemirror? I get that maybe the parsing is unavoidable but what about using something like a page mark that can be hidden or visible depending on the viewport?