does it work well for 500+ pages?

[Fahad-pnw]

Hi, thanks for opensourcing your work :)

so i randomly tried putting this in umadoc and it kind of failed. so i wonder if you can try large content within your plugin and let me know if it does work without crashing the browser.
https://www.gutenberg.org/cache/epub/75051/pg75051-images.html

[hugs7]

np. Surprisingly it performs decently for that much content when I try - I don't get any crashes and I'm able to make edits with some lag. There might be some performance improvements but we are limited in what we can do due to tiptap being content editable

[Fahad-pnw]

thank you for responding so quick!
can you also publish a repo with a sample? i tried pulling yours in a fresh tiptap and it was just one input box with tiptap without this page toolbar on top, like you have :))

[hugs7]

np. See #27. The toolbar I have isn't part of this repo since this is the extension only - it gives you the power to have pages in your editor, not the toolbar. Same way that the table extension allows you to have tables but doesn't provide a toolbar to interface with.

I've been working on #36 (see #39 for the active PR). It's fairly complex so might take me a while but if I get this working to a decent standard I'll consider putting a demo page together.

[hugs7]

Further to the above, the other reason for the toolbar not being a part of this repo is it should be agnostic of how consuming projects want the toolbar to be styled. E.g. in my ss above I'm using Material UI but someone else might want to use something different. So if I do end up making a demo page, it'll be a separate repo to keep dependencies down in this one

[ArihantBapna]

Would it be possible to make performance improvements by using intersection observer and then only render the contents of a page when its in view?

[hugs7]

Interesting. Yeah possibly but I guess it really comes down to if Tiptap/prosemirror supports it. I.e. there might be some limitation we don't know about.
It's not a priority for me but I'll keep your issue open

[hugs7]

I've done a bit of looking into this. While I don't think we can use an intersection observer, the algorithm for updating the page content could potentially be optimised a bit. We can't use an intersection observer (from what I can see) because code in this repo doesn't actually handle rendering the page nodes - all it does is apply some styling to the page node to set the height, width, margins, etc. Because I can't trigger the addNodeView method here file manually (as ProseMirror handles when to trigger the update), I couldn't even say don't apply styling unless the page node is in view.

If anything, your feature request here should (imo) be directed towards Tiptap/PM. Having pages doesn't really have anything to do with it - it's just that currently the entire document is recomputed whenever a node height changes or you add/remove a node (e.g. Enter/Backspace/Delete key). For example, you could have some other kind of node which is "heavy" and have the same performance problem with a really long document since that node would still be rendered (added to the DOM) even if it's far outside the viewport.

Following on from my first sentence, what I might be able to do is in the update method within https://github.com/hugs7/tiptap-extension-pagination/blob/7fbe0609982cc8fe77f4d9d552511e278c25b879/src/Plugins/Pagination.ts#L25, somehow be a bit more efficient in computing a new document, rather than re-rendering an entire new one each time. If we ignore multi-user support for a moment, we know that wherever the current selection is, that must be where the update just happened. So we can inspect nodes here, and do one of the following

• Move a node or nodes to the next page if the cumulative height of the page's content exceeds its height. This would use very similar logic to here. We would still need to add this node to the next page of course, and keep checking page heights until we either reach the end of the document, or, in the ideal case, reach a page where we don't exceed the available content height.
• If we have space available on the current page (i.e. we've deleted content on the current page), move content nodes from subsequent pages to the current page until it fills up (also using here logic). We would need to keep doing this until the end of the document or until we reach a page where we can't squeeze any more content in.

This way, performance should hopefully be improved a bit but performance would be (slightly) biased to editing at the end of the document, since we never have to check above the current selection, but we do below it.

Again, this isn't really a priority for me but happy to leave it open and revisit it in the future.

[ArihantBapna]

Yep! Thanks for taking a look, if you keep this issue open, I'll give it a shot as well