"Auto-Save" persistent document storage

[Keavon]

We should store the open documents and the artwork within each document in localStorage or IndexedDB. Other state, like the current tool and working colors, would be a nice bonus. This helps restore previous sessions if the user accidentally closes the browser tab (for example, while intending to use a keyboard shortcut to close a document tab).

The UX of this should work based on the "Auto-Save" feature. When enabled, every change is saved locally and automatically restored on the next visit. When disabled, any saves are discarded and not saved, so the next visit will not reopen any saved documents.

IndexedDB should be used, not localStorage, because we want to store proper binary data and not be limited to a string. This is how VS Code's online editor (at vscode.dev) does it.

Soft-blocked on #324.

[tillarnold]

A thing to keep in mind is that, as far as I know, localStorage is usually restricted to 5MB, so once documents can contain bitmap images that might become a problem.

[Keavon]

That's true, and localStorage is also unfortunately restricted to the string data type only, so you have to convert it to base64 or JSON which takes up even more storage space. But I think bitmaps are still a bit further away on the roadmap.

[azeemba]

I am looking at this issue and had a question about which component should be responsible for doing this. Since I think additional work is needed based on the decision we make, I wanted to bring it up.

From the UI side, the Document component has the contents of the canvas but doesn't know about other tabs. The Workspace component knows about the tabs but it only knows the index and the name of a tab, not the content.

So it makes it tricky to decide who should be responsible for persisting the content. A simple solution would be to make sure that the Document knows what its index is and let each document store its content based on index. Another solution would be to expose the content of each tab to the Workspace component and let it handle persistence.

[Keavon]

I believe the plan is for the backend to serialize the state of its documents, then send a message to the frontend which the Response Handler receives and calls the localStorage API.

Perhaps the UX could work based on File > Save and File > Open. We may want to provide the user a way of naming unsaved documents also, but I can worry about the frontend implementation of that and we can stick to the default document names for now.

I think the first step for this might be implementing a way of downloading and uploading Graphite documents, perhaps with a .gsvg file format ("Graphite SVG"). This format will be used until Graphite 0.2 when we have a proper node graph and the .gdd ("Graphite Design Document") format. Once that step is implemented, then we can worry about including that in localStorage.