Gutenberg: Store (some) data offline in parallel to posting it to the API

[tofumatt]

As part of #6322, we should be storing post data and other things we'd submit to the REST API also offline in offline storage. It's probably best to use something like localForage for this task or something else that lets us access IndexedDB easily, because localStorage's API is blocking, it has a small data limit, and won't let us grow if we want to do things like save media offline for background uploading (like the mobile apps).

To start with this we probably just want to save anything we post to the REST API offline so data isn't lost. After that we may want the app to look for offline data that is newer than what's on the server and restore that instead.

[tofumatt]

FYI: I've experimented with this and saving the data offline is straightforward, but right now it's not possible to only implement this in core-data, because certain autosave actions and other requests happen outside it, so stuff like autosave has to be managed/dealt with separately.

I think something like #7546 might help implement this because the offline storage shouldn't be blocking either.

For now I'm leaving this because the implementations I managed to get working locally were hacky and not future-looking, but once everything is moved to core-data I think I can look at this again.

[westonruter]

As noted in https://github.com/WordPress/gutenberg/issues/6322#issuecomment-410578818 what about using service workers for this? Background sync could be used to push anything to the server once reconnected, and in the mean time anything PUT could be used as the response for a GET request.

[tofumatt]

Yup, it's definitely possible to use service workers, I'd just want to make sure we're okay with it being a progressive enhancement then, as IE 11 users and earlier iOS users will miss out.

[danielbachhuber]

@tofumatt Was this addressed or does it need additional work?

[aduth]

Related: #9383

[tofumatt]

It needs more work and I have not been able to give it the attention it needs. I’ll probably have to leave it out of the release; not sure if anyone else has bandwidth for it.

• Matt (Sent from mobile)

On 18 Oct 2018, at 19:20, Andrew Duthie [e-mail] wrote:

Related: #9383

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[getsource]

Going to drop this back into 5.0 for consideration, to see if anyone else has time to handle this. I don't think we need to make the experience better than it is in TinyMCE, but to me -- at least matching that reliability in terms of saved/lost posts is important.

[mtias]

Is anyone working on this at the moment?

[tofumatt]

No, and while I'd like to, I've unassigned myself for now so someone else potentially interested doesn't skip over it because they see my assignment.

I've moved it out of this milestone for now.

[mtias]

Thanks.

[danielbachhuber]

@tofumatt @mtias Are we knowingly dropping this from the 5.0 release?

[getsource]

To be more precise: Does this mean that you're deciding to drop this feature from WordPress?

[tofumatt]

We’re dropping this from the 5.0 release but not from WordPress.

[jdevalk]

We’re dropping this from the 5.0 release but not from WordPress.

I'm sorry but this is not how it works. Consider this: if your email client, that has always auto-saved your drafts, suddenly no longer auto-saves them. You complain, and the response it: "yeah we hope to get that back by the next version." Is that reliable software in your eyes?

[tofumatt]

There are plenty of new versions of software, especially big rewrites/re-imaginings that remove features. Gmail does it, MacOS does it, etc. I understand the desire for backward-compatibility and not losing features, but I don't think we can ship a _good_ implementation now.

"Reliable software" could just as easily mean "software that isn't buggy and is well-tested" as "software whose feature set never changes". In this case: striving for the former neglects the latter, yes. That is not always the case and I agree: it's not ideal.

---

I've been working on a patch that uses localForage to save the data but just noticed the error that it's not compatible with WordPress's license. That's my bad, but I think any approach that uses localStorage instead (the only "fast-to-implement" option) would either break or require a migration strategy in the future.

I would rather do this right later, because we won't even be exposing UI for this; just saving the data for now. And if a plugin is written to restore that data we'll essentially have an API to support that we don't like.

I think it's too rushed a timeline to ship this feature for WordPress 5.0.