I’m start to using persist-collection package (https://atmospherejs.com/stumps/persist-collection) and I saw is very useful for my app.
I made an app that use collection in pub/sub mode, minimongo keep data only in memory and for this everytime I’m loggin data is load from server.
I would keep data in local side, for using also in offline mode.
Due to this, I get persist-collection package that save data from minimongo in local storage, but the structure of data is different from original collection for field “_id” (key): in minimongo collection data is like “{_id: key, field1: value1, field2: value2…}” while in local storage is “{key: {field1: value1, field2: value2…}}”, and I have to transform data for usage in all my app, using something like:
Collection.getPersisted().then(res => {Object.keys(res).map(key => Object.assign({}, res[key], {_id: key}));});
Now, I though to modify persist-collection for store data in original mode and remove the data trasformation which obviously weighs down the client.
Anyone have some advice to give me ?
Keep in mind that localStorage is limited to 5 MB of size in Chrome and probably similarly limited in other browsers. Whereas e.g. IndexedDB is practically unlimited in size, as it uses the cache allotted to the browser by the OS.
However the IndexedDB’s API is a nightmare, but there are wrappers that mitigate the problem. I use Dexie.js and it works just fine. Also Meteor uses IndexedDB for caching code for dynamic imports.
As with IndexedDB/dexie.js the data saved wouldn’t be altered.
Sorry, I’m wrong, persist-collection package use IndexedDB or websql, not localstorage, so there is’nt the size problems of space.
The persist-collection package give me an “out of the box” situation, if you read documentation, you can see is very fast and simple to implement in normal pub/sub environment.
Is almost all transparent and there is a few thing to change.
Only the issue that have describe in my original post make me some troubles.
That seems to be a rather unfortunate implementation detail in persist-collection that could only be changed by rewriting the package. It may have to do something with the WebSQL standard, but that’s just a wild guess. As far as IndexedDB is concerned, documents can be stored exactly as they are in MongoDB. Sorry that I couldn’t help.
Thanks anyway.
Maybe someone who uses it can give me some tips…
The author mentions this is an experimental library and expects more feedback from users on the synchronisation scenarios.
Not sure if you noticed this section ’ NOTE ON SYNCHRONIZATION (IMPORTANT!):’
I would suggest to abandon this library and build your case with more modern tools. I see you want a combination of reactivity while online and persist data for offline but that is a bit of a Utopia because of the syncronization hell.
Example:
My user name is Jimmy. I go in my offline mobile app and change my name to Tim. I then go in my web browser (online) and change my name to John. I go online with my mobile app. What is my username?!
When I needed offline, I built apps that performed well offline (with Realm DB)and only synced in one direction at a time while no updates would happen on the server (kinda like I have this ticket, I work on it, nobody else has it, nobody else updates it). Download the ticket, work on it, upload (save) the ticket back to server. Sync both ways is just … nightmare, a lot of tech to write.
How much do you need the reactivity in your project?
thanx.
My need is to have a lot of reactivity and a lot of “good offline behaviour”… I will tried to get a valid solution…
When go online my app want to synchronize data but before to save, it check the old data (Jimmy) with actual data in server (John), if there is a difference throw an “exception” of data conflict, showing a message to the user that data (Jimmy) is changed at the time with a new value (John); than I can reload a actual data (John) or overwrite with new (Tim), acknowledging the state.
I think is a valid behavior for data changes in both side.
But normally it is difficult for a data to be changed at the same time, yes, it depends on the application but for what I think this solution could be fine.
Would be a bit like the concept of “optimistic update”.
Yes you are perfectly right, it can be done but as I said previously “a lot of tech to write”. Some things are easy to build offline, pretty basic, others are very complex offline while very basic online due to reactivity through Minimongo. It is a possibly a function of design and resources and my believe and understanding is that it can be done with methods leaving Minimongo aside.