As I understand it I can use change events to update my UI. But in case of multiple changes that means I update my UI multiple times per sync. Is there a smarter way?
Maybe have some kind of run loop and collect changes within an interval you define yourself?
I’d say that belongs into the library. Some event like “sync-done” and a param saying if there were updates or not. Would that be possible?
I don’t see why the library should handle that. It’s specific to your UI and framework. In modern JavaScript frameworks, the framework core should handle efficient UI updates by using bindings and a run loop.
So how does my app or the modern framework know when to run the loop to update the UI?
Wait, that was too quick. So you mean I delay the updating. Is that all that the run loop is about? I’m just looking for a smarter way as network latency is hard to guess. If remoteStorage.js could do this, why not? Just not sure how it works internally hence my question if it would be possible. If the only way is to wait for a while I agree this doesn’t need to be in the lib.
What I meant was that you can throw as many data updates as you want at a modern framework, and it should figure out itself how many times it wants to update the affected parts of the UI.
I agree that there could be an event indicating a finished sync, though. Just don’t see why I would ever need it in my own apps.
I think I may have misunderstood the question. Are you talking about performance, or do you need the feature for UX reasons?
Primarily for a clean and timely display of updates so UX, yes.
Then you could just show the updates since last sync, and collect new ones until the next sync is done:
http://remotestorage.io/doc/code/files/remotestorage-js.html#RemoteStorage.sync-done
You can even write a helper function using rs.js events to emit a new change event for all objects since last sync, and in that way prototype the functionality you may want to propose as core feature.
That is exactly what I was looking for.
Great, glad I could help then. Sorry for the confusion at first. 
Here’s a use-case:
- There’s lots of data in my remote storage
- None or only parts of that is currently in my web storage (browser) as I haven’t connected at all from this browser or syncing is a while ago
- My app wants to display all that data at once (like a list of all my favorite drinks)
Now when I connect, syncing starts and gives me lots of change events for all that fresh remote data. Depending on network speed and server response time these event may be triggered over the course of multiple seconds. Updating the UI on every change event might cause things to jump around or what ever.
Things jumping around is a general UI problem but updating the UI only once per sync makes sense, no?
This is exactly why we want to fix BaseClient#getAll. It’s not a problem of a feature missing, but of an existing feature behaving poorly (I’d even say being broken).
Ok.
What if there’s lots of changes since last sync?
I don’t understand the question. You mean in terms of performance?
If I want to load data from local cache when starting the instead of waiting for the server with getAll I can get the cached data listening to change events (‘local’). Now I get hundreds of event (one per data entry). How do I update my UI (an ordered list of these entries) efficiently? Is there a way to get all local data in one list or something?
It seems like the main problem here is that some use-cases don’t really apply to single-events per record, and it would be better to get complete lists. Because of their nature events can’t do this, but a function call can.
It seems like what @xMartin would like would be something like the following sequence:
- populate the app immediately with all cached data provided in a single list
- get all updates in a single list
- set change events for single entry updates as they come in
Is this correct?
The problem with change events is you have no way of knowing in what order they will come in, and it’s very annoying as a user to have a list of entries, and as new entries come in your list jumps around and change order. You want to be able to show to the user that you have an existing list, and currently new entries are being fetched, then here are the new entries (think twitter app). You can’t do this with change events.
If getAll had an optional boolean flag as a parameter to indicate cache-only or check for updates from server. Then you could implement that type of UI.
you’re expected to build that list in memory, in the module. that way your code can access the data without roundtrips to IndexedDB.
He’s doing that already. The question with an unkown amount of change events is how are you supposed to decide when to show it in the UI then? You want that to be as soon as possible, and that means you want rs.js to tell you when everything’s fetched.