Recently I was integrating the new noglobal versions of the library and the new widget into a few apps.
I noticed that currently it feels a little odd that loading the widget and any modules happen implicitly by just importing them. Also there is an inherent order for the imports, in that the RemoteStorage library has to be imported first.
I talked to @raucao about it and we had a few first ideas how this could be improved.
E.g. the module loading could look something like
import Bookmarks from 'remotestorage-module-bookmarks';
import Documents from 'remotestorage-module-documents';
import RemoteStorage from 'remotestoragejs';
let rs = new RemoteStorage({ modules: [Bookmarks, Documents] });
This way it would also be possible to use several remoteStorage instances that use different modules.
As for the widget, that could be loaded like
import Widget from 'remotestorage-widget';
let widget = new Widget({remoteStorage: rs});
widget.attach('#someElement');
This is all just a first broad idea that I would like to get some feedback on.
\o/
I was thinking about a way to change that too, so this would be more than welcome to me.
the only thing I would change in your example would be to have just one package in npm for modules so you will do something like:
import {Bookmarks, Documents} from 'remotestorage-modules'
import RemoteStorage from 'remotestoragejs'
let rs = new Remotestorage({ modules: [Bookmarks, Documents] })
but this is personal and not important aesthetic stuff.
about the widget it’s ok too, I was also searching another way to specify how to connect the RS instance and the widget when they cannot be in the same context.
e.g. in browser extensions, you usually would have the RS instance in background and the widget in the option page or inside a popup page, and scopes are not shared between these pages, but you can communicate via messages or callbacks, so would be great to have another option to connect rs and the widget, but this is a specific case, I think I would implement it if it’s ok for you (that would be 2 methods both in RS and widget to send and receive events).
@galfert - I had similar thoughts as well when I was using RS in a node environment a while back. I think the API interfaces and initialization process you laid out (with @les’s changes) look great.
@les I like the idea about sending / receiving messages from other contexts (I was thinking, for example, a browser plugin or a worker thread).
I think the idea of using separate packages for every module is to have them more decentralized. That way each module can have different maintainers. And you can better define dependencies to other modules, including their version.
I like your idea about the message sending and receiving to support different contexts. Especially if that benefits us in using Web workers as @silverbucket mentioned. Please let us know if we can help in any way with that.
