Facilitate offline editing in Gutenberg via caching and background sync for REST API responses

[westonruter]

See WordPress/gutenberg#6322 (comment)

This ticket goes along with the re-introduction of Turbo mode (#34). Beyond caching of assets and admin screens, we also need to allow REST API calls to be made offline and to use background sync to push changes to REST API resources once re-connected.

[miina]

Note: planning to pick this up and create a small proof of concept for starters.

[miina]

General planned feature overview:

The implemented "Turbo mode" is responsible for getting all the scripts and styles cached for the editor. The admin service worker is serving an offline page that currently just displays information about being offline (or errors). This page will instead show a list of draft posts available for editing offline. Ideally, it will also include a link for creating a new post which will always be saved as a draft when going back online.

For enabling that, we will need to include REST API responses for those posts for caching.

When the user comes back online, the Workbox Background Sync feature will push the updates to the DB which also brings up the question of what to do with the posts that have been modified meanwhile by someone else.

One option would be just saving the changes as revisions, a more sophisticated alternative suggest by @westonruter is logged here, see also the trac ticket. To summarize: we need to extend the REST API to include If-Unmodified-Since header when doing PUT request. If the post has been modified, the update request would fail (412) and create a revision instead.

Displaying posts only when logged in.
For the user to be able to edit offline, the user has to be logged in previously while still online. Whenever navigating to a page, the user ID and also REST API nonce need to be sent to the service worker. The logging out button should work by clearing this information from Service Worker and setting the user ID to 0. This ensures that on a shared computer it's still possible to log out even though offline -- this would both "log out from offline interface" and also actually log out after getting back online.

1. For the proof of concept (without offline reading):

• Allow editing a previously loaded post only.
• Display a message about being offline and let the user know that it will be updated later.
• First step: either ignore changes done by anyone else or always create a revision.
• Second step: Use If-Unmodified-Since and create a revision only if the post has been modified meanwhile.

@westonruter Let me know if you have any additional thoughts.

[westonruter]

The implemented "Turbo mode" is responsible for getting all the scripts and styles cached for the editor.

A note regarding Turbo mode which is not a dependency for this work here, but it is something which would be good to improve in the future: I believe that the Turbo mode as implemented in the PWA plugin is perhaps overkill in that it caches way more scripts and styles than the user may ever need. The original Turbo mode in WordPress only cached scripts/styles used by the post editor, so I think that model should be retained here. Also, instead of adding the assets to the precache, it may be better to switch to putting them in a runtime cache, caching them on the fly when first accessing the page. This will ensure other assets for third-party blocks also get included. These cached assets can then be served with a network-first strategy.

When the user comes back online, the Workbox Background Sync feature will push the updates to the DB which also brings up the question of what to do with the posts that have been modified meanwhile by someone else.

In regards to Background Sync, note that Periodic Sync is currently under origin trial in Chrome. Once that is generally available, then the admin app could proactively fetch updates to posts (e.g. drafts) in WordPress so that they would already be available for editing if the user opens the app while offline.

One option would be just saving the changes as revisions, a more sophisticated alternative suggest by @westonruter is logged here, see also the trac ticket.

I don't think these are actually alternatives: both are required. When background sync happens, we need to (1) update the post or else (2) create an autosave revision in case of conflict. The first part would ideally be done in one PUT request with an If-Unmodified-Since request header, but we could fake it by doing a GET request immediately followed by the PUT if there is no conflict detected. There would be a tiny window where a user could override someone else's changes, but that would be uncommon.

When background sync detects a conflict and stores the changes in an autosave revision, it will be important to communicate the conflict to the user. There is currently a warning notice on the edit post screen an autosave revision which is more current than the saved post:

But eventually, this message should probably be proactively told to the user before they even access the edit post screen, by perhaps some push notification or some message on the admin dashboard.