The subscription method uses the spread operator. This means that I can add any kind of second parameter to the api.sub method including an array.
About the find function. Its indeed a non-reactive function. I’m doing this to make it easy to include it as SSR feature. It still needs to be connected to Vue’s reactivity system, but I want to wait with it, because of your next release.
The reactive part will also become a Vuex feature since that store uses convinient methods to pull this off easily.
That said. Not sure if this is the right approach. I’m always open for feedback
About the fetch part. Thanks for that. The example code for find should not have had the await part. I will remove this
I see your point, I am not familiar with Vue.js, but I am going to make reactivity by mutating the returned object. So it will be a plain js array or object anyway, just like now. Is it ok for SSR?
@gregivy Congratulations and thank you very much for this amazing work! I am developing a chrome extension connected to a Meteor back-end and was upset with the DDP clients currently available.
One question I have open is: Since it is not possible to require modules on chrome extensions without a huge workaround, is there a way I can use your DDP directly on my project? (I mean, instead of installing through NPM and then requiring)
What do I need to do to call methods through simpleDDP on my chrome extension’s popup?
Should I import { simpleDDP } from bundle.js on my popup.js file?
The above approach works fine, except for the callback of the call…
When I run the code below, the method is called (because the console log appears), but its callback is not:
What I know from other DDPs is that sometimes calls don’t return callbacks, but rather promises or something different. I also tried the code below, without success:
I think I have to hold over a bit publishing version 1.2.0 because right now I am deeply testing it with different mobile web views and have some problems with scenarios like the lose of the internet connection and reconnection some time after etc.
I found some really disturbing bug!
If you connect to meteor server, subscribe for some publication, disconnect for long enough (>10s), make some changes in the publishing data and then reconnect again - simpleDDP local collection will be messed up. Instead of updating changed documents to the latest state, simpleDDP will make a duplicate with the same id inside its local collection. This happens because the newly created subscription does not know anything about it previous state and will send added ddp messages.
This behavior is fixed in 1.2.0.
However there are some questions left with removed ddp sync in the same scenario.
I have replaced ddp.js with simpleddp-core. It is the same old ddp.js but with PRs included and few bugs excluded
Right now I am making tests, fixing some errors, improving API and reading Meteor repo about DDP. There are a lof of things I need to consider in 1.2.0.
I am planning to make a good guide and push it to github pages, so if someone is willing to help and knows good constuctor or something like this you’re welcome
Thanks for the heads up! I’m looking for a way to make this pluggable since React, Vue and Angular all have slightly different ways of connecting their Reactivity system. Any thoughts on it? right now I’m actually considering mapping onChange, etc to the Vue Store and create a local DB’ish storage there.
This means that this.user is a reactive data source, when there is no data it is an empty object, when some changes happen it is being mutated to the right state. The key word is mutated, so the object remains the same until you remove this.userCursor.
The code reactiveOne({preserve:true}) means that we want a reactive data source as a first object passing previous conditions (filter in my example), and {preserve:true} means that if object is being removed by the subscription it stays untouched in simpleDDP collection storage.
If we use reactiveOne() or reactiveOne({preserve:false}) then there will be empty object {} in case of publication removes it. But it will be the same object, not some new {}.
If you need more complex behavior you can use onChange:
this.userObserver = this.userCursor.onChange({prev,next,fields}=>{
// prev is previous state of the object or false if none
// next is new state of the object or false if none
// fields is an associative array of changed fields inside the document
// (value 1 means property was changed, 0 means removed)
if ( prev && next && prev.score > next.score) {
alert('You lost some points!');
}
});