Google and Dropbox remote storage backends should be optional add-on modules

[rchrd2]

I notice they are being included and initialized by default. In many cases, these might not be used, so it would be ideal if they were optional.

On a high level, here are some ideas:

In the dist folder they could be separate fles: eg remotestorage-google.js.
For import it could be something like `import GoogleStorage from 'remotestoragejs-google';

Here is a screenshot showing that they are included with the standard import RemoteStorage from 'remotestoragejs';.

[raucao]

The back-ends are actually opt-in. The feature is built into the code, but it will only be used when you configure OAuth app keys via RemoteStorage#setApiKeys.

Also, if these are not set, then the connect widget will not show any options to choose from, and instead open the connect form for remoteStorage accounts directly. You can see an example of that on https://sharesome.5apps.com.

How it works in the code: remoteStorage.remote will be initialized as one of WireClient, Dropbox or GoogleDrive when connecting a storage. So basically the two non-standard options are mostly different implementations of WireClient.

Hope this helps.

[rchrd2]

Yes. My proposal is to remove Dropbox and GoogleDrive from being included in the core codebase. As it is now, if you aren't using them, the clients are still included in RemoteStorageJS.

Additionaly, I think that if they were separate modules that could be optionally included, it would also make it easier for others to create their own remote storage option. All the necessary hook-ins would be be setup as a consequence of keeping Dropbox and Google separate.

I understand that this might not be the highest priority, but I wanted to point it out.

Thanks for your consideration.

[raucao]

I see. They're not actually taking up enough space for that to be a drawback currently. But I think it would be nice to make them seperate modules and with that create a proper API for additional back-ends. As you say, there are currently more important areas to focus on, but let's keep it open so potential contributors can find it.

I changed the title of the issue to reflect the nature of the proposal a little bit better. Think it's OK like this?