Well, I am pro reactivity, but I also can agree that there are times reactivity is not wanted.
One reason would be UX, where you don’t want the current UI to change until after you want it to.
Another reason would be static data sources, or sources where you know will not change often, and performance is a big concern, so much so that introducing collections and pub/sub where they are not necessary may be bad. And is extra work.
So in essence I’m not looking at this as removing reactivity. I see it as adding it when it is necessary.
I may live with querying facebook for a user’s latest posts on demand rather than polling it every T seconds and loading them onto a collection or a custom reactive data source for reactively displaying on the client.
Yep, that makes sense to me, and we actually did the exact thing in my most recent application.
We put a toggle in that disables reactivity on click. If the value evaluates to false, then the Cursor is returned by the Template Helper as-is. If it evaluates to true, we call the Cursor’s .fetch() method and then return that to the Template.
Since fetch returns a simple array, there’s no reactivity to kill and we didn’t have to change any other logic. The only catch is we have to manually refresh the array when the need arises.
1 Like
@sparser that’s really interesting. Was that an internal business app? How did you explain your users what that toggle does ?
In fact I’m doing that as well, chaining an extra fetch to the find to kill reactivity, but that’s so far been my decision as a developer. It never occured to me that I could actually mold that into a feature.
@Sparser - Thanks for replying. @serkandurusoy has added few reasons why we want to avoid reactivity. App mostly display static data and the screen update is driven by user actions.
And other reason : We cannot load MongoDB with polling queries or also no single oplog, as we use sharded MongoDB with few TB of data.
Yeah it is. We didn’t do much, to be honest. We left reactivity on by default and made sure the toggle was visible and clearly labeled.
Only my, ahem, older stakeholder even wanted it in place.
1 Like
I might ask why you’re going with Meteor.js then. A more traditional MEAN stack might make more sense?
If you’re staying, Methods make the most sense for this.
Yes, external sharded MongoDB datasource. And no extra work of polling queries / no oplog.
To avoid most of housekeeping efforts required for device compatability / java script packaging / full stack environment and make developer env simple and easy.
You can also get the convenience factor from something like this
@Sparser
We have tried with Curser’s .fetch() to disable reactivity. Any updates to datasource not propogated to client. But still, Meteor is triggering queries to MongoDB.
You could try using fast-render to write the initial dataset, copy it into something persistent in the client layer, and then cancel the subscription by calling “stop” on the subscription object.
We have tried with {reactive:false}, but we still see polling queries every 10 secs on MongoDB.
Hmm, you may want to look into ways of accessing mongodb directly rather than a meteor collection.
There should be some packages on atmosphere that let you bypass meteor and access the native mongo driver for your own static queries.
Also, I think meteor also exposes that with an api named something like mongoInternals that I’m not experienced with but worth looking into.
I use both the official MongoDB driver and Mongoose for some of my other projects. I recommend either one.
Well how about that …
A version of https://atmospherejs.com/richsilv/dumb-collections just got released.
Might be relevant to this conversation.
@Sparser - Can you please give some pointers how to fetch result sets manually to client and prevent reactivity ?
If you really want to continue to use collections you could use a server method to get the data out of the DB, then insert the results into a client only collection (initialized with null instead of the name of the collection).
var MyCollection = new Meteor.Collection(null);
Meteor.call('getData', function (docs) {
_.each(docs, function (x) {
MyCollection.insert(x);
});
});
The point of reactive:false is to stop the any template or autorun that uses that cursor from re-running when the cursor changes, on the client. This won’t stop Meteor from polling the database for changes. If you call a subscription your database will be polled(or the oplog observed).
1 Like
You have two alternatives there:
a) Don’t use the built in accounts system
b) Fork the accounts packages, change their queries and publications so that they are not reactive
But (b) will require you to change a lot of things since the whole accounts system is built around the idea of reactivity.
Therefore, I think you’ll be better of doing (a) and writing your own non-reactive accounts system.
I’ve reached this interesting conversation, and I want to ask for your opinion in a very similar situation as @sambapotla:
- I don’t need reactivity (at least right now, maybe in middle-term future for notifications, but let’s assume I don’t need it at all). Actually, let’s say I don’t want reactivity.
- Why using Meteor then? Because I have a veeery tight time constraint, I’ve been the last 2 years mainly a Frontend developer (though I have some Java backend knowledge from years ago), and Meteor seems to me a super fast way of building a website with my, let’s say, limited knowledge.
- So for “avoiding” reactivity, I am basically doing Method calls, because as I understand it, methods are not reactive (am I right?).
This makes any sense?
Also @Sparser, you commented that making methods is a ton of work. If I didn’t care about reactivity, I would make use of publish and suscriptions, right? So I think: to do saves/updates checking authentication would be need to make Allow/Deny rules… (am I right?), meaning that the work will be more or less the same.
Sorry if I say too much wrong sentences, I am just trying to make 100% sense of Meteor in my head, but I think I am missing pieces in a bunch of places.
Cheers!!
Yes @eviljohn, I am same boat as you for all three points mentioned by you. My app doesn’t need reactivity other than a screen, and we have very few developers to build the app.
I am not sure of addiotional effort required for methods approach -
Server side, finding data from database - same effort, query in method vs publish block of code
Additional effort on client, method success call puting data into a ReactiveVAR or something to make it accessable for template helpers. Whereas, subscription puts data in minimango, and helpers would read from minimongo.