Save in-progress draft in browser storage

[Benaiah]

- Do you want to request a feature or report a bug?

feature

- What is the current behavior?

If you are working on a post in the CMS and your browser crashes, all your work disappears.

- What is the expected behavior?

Save in-progress entry drafts to local browser storage and offer to restore that version if it's different.

[erquhart]

Quick thoughts:

• We'd need to track two kinds of changesets - new entries and existing entries
• When any entry is successfully persisted, we should delete the local changeset

New entries:

• We could retain one changeset per entry type
• Instead of offering to restore, we could auto-populate the local changeset every time, accompanied by some kind of communication that saved changes are present. Github uses color for this, but we should avoid that level of UI nuance at this point.

Existing entries:

• Every entry can store a separate changeset locally
• Auto-populating would be great here, but successful communication requires an even greater level of UI consideration than for new entries. Maybe best to just offer restoration for now.

Down the road:
Persisting auto-saves to a live backend would be amazing. Unlikely to happen near-term, but maybe.

[erquhart]

Follow-up:

This is subject to rate limits, but we could push commits in the background as auto-saves (with history!), and use squash merge when the entry is persisted or published. Not certain if GitHub squash merging is risky, seems like it should work fine for this use case.

We could supplement this with cheap localstorage auto-saves for offline users.

[tech4him1]

This is also relevant if the API itself has problems, in which case we have to use the browser-side solution.