It might be good enough without it, but the undo stack was the last big requirement.  The print function may or may not be a buster.  Another really nice but unessential feature is a grid.

With the login sequence forcing reloads, the undo stack becomes eternal & server resident.  This would be a memory resident undo stack on the server.  Kill the server & lose the undo stack like a regular program.

Lions have always saved an undo & redo stack.  In this case, the last redo buffer would also go on disk as a saved project.  Helas, when the user undid a level, the saved project would no longer be the current redo buffer & the browser would have to show a modified flag.  The big problem is the program has to save the project to handle a login attempt, which erases the undo history.  The mane things which cause a login attempt without the user editing anything are a page reload & the resync button.  It's almost useless beyond 1 level of undo.

Thus began the battle of the apply buttons.

Text entry & font size need apply buttons to propagate text from the user entry to the PDF & they need an edit button to propagate text from the PDF to the user entry.  It's a compromise a lot of PCB editors make to keep every keypress from expanding the undo stack.  Automatically updating the PDF while typing in text doesn't allow entering replacement text & later selecting a destination for it.  Automatically copying the PDF to the user entry upon selection created the problem of unintentionally overwriting previously entered replacement text.

The mane reason font size & text contents need apply buttons is the chance of keypresses getting dropped because the program is busy saving undo buffers & redrawing.  It's not a problem to drop scroll wheel events but all the keypress events needs to be processed.

A final reason for having to apply the text contents is the chance of a change in the text triggering an open auth login.  That would be very disruptive.

The only automatic update is a mouse wheel change to the font size.  Undoing mouse wheel events for the font size is the hardest undo operation.  The undo operation is too slow to undo every incremental font size change but some clever programming can compress all the incremental size changes into a single undo & redo buffer.

All this yielded a somewhat complicated system of edit & apply buttons.  Maybe there are more automated ways of handling text entry with asynchronous polling loops.

That just leaves print, row, column, cut, copy operations.

Finally, the killer bug is when a fetch fails, it kills the async chain & the busy flag is never unset.  The undo buffer is definitely hosed if there's a network error but there's a good chance the document is still preserved.

Every fetch call needs a

.catch(e => {
            console.error(e);
        });