Event listeners and developer indicating intent

[silverbucket]

Hi All,

I apologize if some of this stuff has been discussed (at length) before, but I haven’t touched much with remoteStorage modules in a few months, and just recently started working with the documents module for a demo, so I’m looking at this with new eyes. Some comments/questions…

Currently, it seems modules need a carry out a few steps that aren’t so clear.

1. Issue a release on privateClient (don’t sync anything)
2. Issue a release on publicClient (don’t sync anything)
3. When a listing (subdir, or root of the module) is requested then use it (sync this)
4. Write a wrapper for the on() function to filter out events not applicable to this listing.

There are a few things that don’t really seem logical here

• Intent

Why are we defaulting to sync everything, only to initially unsync everything - which i’ve been told is the way you are supposed to do it - then pick and choose which paths to sync? That’s a very confusing paradigm.

• Filtering Events

Once you’ve indicated you’re only going to use, the module still needs to implement boiler plate code to filter a bunch of chang events that you’ve effectively already said you are not syncing and you don’t care about. You are defining the listener events based on the listing you’ve requested, so why are we sending (potentially) hundreds of document change events to a listing that’s not on the same path?

For example:

`

remoteStorage.claimAccess({documents:'rw'}).then(function () {
  remoteStorage.displayWidget('remotestorage-connect');
  remoteStorage.documents.init();
  invoices = remoteStorage.documents.getPrivateList('invoices');

  invoices.getAll().then(function (list) {
    for (var key in list) {
      App.addInvoice(list[key].content);
    }
  });

  invoices.on('change', function () {
    console.log('RS onChange fired!', arguments);
  });

  invoices.on('error', function () {
    console.log('RS onError fired!', arguments);
  });
});

`

That’s from a demo app I’m working on. Without the document module filtering the change events, I get one change event for every single document in the documents module. Even though I’ve released everything, and used just ‘invoices’.

It could save a ton of resources (think mobile devices) if the remoteStorage client library could be told at a more base level to ignore anything and everything not in this listing, because it’s all the app will be working with. This means the remoteStorage client and discard considering each file for a potential change event much earlier than sending them up the chain only to be filtered out at the module level. This also means clearer modules, and a clearer way of stating intent.

Interested in any thoughts.
-Nick

[raucao]

I agree in general, although I think the question is mostly about auto-sync and syncing various paths within a module. There are several ways to solve this problem, e.g. options on claimAccess, a standardized init function, etc. – most of them would have in common, that you state your intent, before remoteStorage.js assumes you just want to sync all data of a whole category automatically.

There’s one misunderstanding in the original post:

@silverbucket

When a listing (subdir, or root of the module) is requested then use it (sync this)

This is only how the documents module works. Requesting a listing is just that in other modules: requesting a listing. It’s probably bad naming as well. E.g. the pictures module has the concept of “albums”, so you “open” an album to interact with it. As opening something is a separate act, you can put the init code there, and then list, get, store, etc. as if you would on a non-sharded category with only a single collection of items.

[edit] Sorry, events are the same question as sync, but the solution must make it possible to request events for different paths than sync. Coupling these is too much of a assumption about what app developers need. I can imagine a couple of scenarios where you might not want to sync a path’s data, but get change events for it.