I’m adding remote storage to an existing app with a Service Worker.
Are there any guidelines or examples?
Should I instantiate once in the foreground (for remotestorage-widget) and once in the service worker, or proxy the calls from remotestorage-widget via postMessage to the instance in the service worker? For the latter, what calls does the widget make to the remotestorage instance?
When the service worker is running without a foreground webpage, it will need to pass a token to connect(userAddress[, token]). How can I extract the token from the remotestorage instance or remotestorage-widget, so I can store and use it later?
I’m not aware of anyone having tried to use the library in SW before. Also, last time we checked if we may be able to move the sync logic to SW background sync, that feature wasn’t available in browsers yet.
No idea really, but I have personally not seen code using a complex JS library in SW before. If you use caching, the sync is usually pretty fast after re-opening an app, and one can tune that performance a lot by adjusting caching and loading behavior.
The RS docs don’t appear to mention member properties on RS that can be publicly accessed. So far, I’ve found the Widget using apiKeys, remote, hasFeature(), backend and reconnect(). Are they private API that shouldn’t be accessed by anything but the Widget?
Thanks for letting me know about remoteStorage.remote.token – it might be useful to document that.
The widget has been split out of the core library with the 1.0.0 release, and we tried to make it so that it only uses public API, so developers can use the same ones to implement their own UI. However, there were some private API remnants and it seems we have overlooked some of them.
I’m not sure why reconnect() is missing from the docs (it’s the latest addition), and we can probably make some of the properties public as well.
hasFeature() is definitely more of an internal thing, but maybe it makes sense to expose some of them via a public property or function (source)
Currently, wireclient.js uses XmlHttpRequest, which is good for wide compatibility. However, to make it work in a Service Worker, it will need to use the Fetch API. I can start work on that; is there a migration plan? Would a pull request be accepted to change wireclient.js to use the Fetch API if available, with a fallback to XHR?
If there’s a working fallback to XHR, then I don’t see why anyone would object. You could e.g. use the feature list/checks that I linked above for the actual implementation. Those already do fallbacks from IndexedDB to localStorage to memory for example.
Discovery only happens when the user is asked to provide their user address, so that shouldn’t happen in a ServiceWorker script. Same for the Webfinger requests.
Testing with myfavoritedrinks should be enough.
That said, I’m still not sure what exactly you made it do in the ServiceWorker. I thought using e.g. sync in the background would necessarily require to use the browser’s background sync API for example. But haven’t really looked into it in detail yet. So it’s not entirely possible to know if testing with myfavoritedrinks is enough, and what to test for exactly in the first place.