Problem
Some documents are very large and they are basically unreadable in the desktop app
For example this document: Zero-Knowledge Multi-Device Identity System
Even on fast computers, it takes a while to open the content tab, because the browser is attempting to mount MANY document nodes all at once.
Thanks to server rendering and highly optimized browsers, large docs tend to be faster on web.
Solution
Ideally we would use windowed rendering techniques. But there are reasons this is difficult.
The first solution will be to ensure memoziation is working so that the app doesn't slow down after the initial render of the document.
Then we should move to a Windowed Rendering solution, ideally one like Arborist which handles collapsing of hierarchies.
Before we perform this optimization, we should probably unify the web and desktop implementations of document.tsx - one of the most complicated components of our application.
Rabbit Holes
Web-Desktop Fragmentation
Do we unify the document.tsx files across web and desktop? That will simplify many things and help ensure consistent UI, but there are challenges with that.
Some challenges with the unification: routing/navigation, mobile support, panels, and differences in features between platforms. Such as block highlighting.
Also, we currently use blocks-content.tsx for rendering all blocks. But we will need to switch to a different implementation for document content. We can re-use the individual block rendering.
Handling Block Selection
What if the user opens the document and is addressing a block that is deep down inside the long document? We need to start the user in the middle of the scroll view, somehow. At this point we will have paginated scrolling up and down.
The scroll bar might be jumping around, because the height of a block is not known until you render it (Due to text layout, image size, screen size, and other variables). So we will need a mechanism to estimate block size for the purpose of scroll bars.
Likewise, it is possible for one block at the top of a large document to link to a block near the bottom of the document. This means we may need to scroll past unrendered blocks, which may have a strange appearance for the user.
Hierarchy
A document appears as a flat list of items, but it is logically a hierarchy. We need to continue supporting the BlockNode collapse which hides children blocks. In some cases, we need blocks to be indented.
No Goes
This solution is meant to handle pagination on the rendering layer only. The whole document will still be loaded into the client, we are not yet planning to paginate the content from the server. Although eventually that will be desirable.