I feel like I must be missing something obvious. Why mess around with ReactiveVars/Dicts at all if you can just read/write to the client db, which is also already reactive?
—t3db0t
Reactivevar is for client (transient) state
You could also use a pure client collection to achieve the same thing.
Well, that’s what I’m talking about. Why use ReactiveVars at all? For convenience, or if you don’t want to use mongo query syntax? But you (probably) ultimately need to sync to the db anyway, so why bother with the middle man?
My question does not pertain to cases in which you don’t need to sync with the server db.
The usual scenario is that you don’t have to sync the client state to the db.
…okaaaay, I rather doubt that, but even if that were true, it’s irrelevant to this thread. Anyone else?
Your right, you don’t have to use reactive var.
However I like to use it, because I find it much easier to reason about when I just have a string/number/boolean that I want to track reactively. With a client side collection, I still have to insert a document, then watch that document. What if I don’t want to reference a sub field on that object? Just to get the data I have to run Collection.findOne().sub_field , and that will blow up if I accidentally add more than one document to the collection.
So that’s why I use reactive var / reactive dict. Sometimes a collection just feels like overkill and adds unnecesary complexity.
What if you want to keep track whether or not a button has been clicked, or whether an XHR request has returned, or an accordion menu has been collapsed or any of a million other things? That is not the kind of state you keep in the database (the server doesn’t need to know about it and it would be slow and the data model doesn’t fit the use case), and that is a large percentage of the client-side state.
So @vjau is totally correct and his answer is definitely not irrelevant to this thread.
2 Likes
What a… 
3 Likes
I get that; I had already stipulated that I’m not talking about client-only matters. Thank you though!
You can’t use reactive vars on the server, because Tracker doesn’t run on the server (well, at least you can’t without some 3rd party packages and serious gymnastics)
1 Like
That’s not what I mean—I mean client applications that need to sync with the db. Not sure how this is getting misunderstood 
I did just think of a reason myself: if you can’t/don’t want to use allow/deny rules and instead are using methods. In this case, you would need an autorun to call the method when the ReactiveVar changes.
Encapsulation
(with an extra for 20 characters limit)
I use Minimongo instead of reactive vars sometimes, in fact often. I use ReactiveVars mainly when doing simple client side state like radio controls, checkboxes, spinners, etc.
Also, I often use Minimongo instead of global Session state. There’s only a couple of scenarios where I use Session anymore, where I have to do calculations and collations that are not already stored in the db. But I’m trying to slowly go through them a pre-store these calculations in the db to.
Also, this idea is not new or extraordinary, and anyone (using Blaze at least) will come to the same conclusion on their own with enough experience.
2 Likes
Have I just walked into some alternate reality where the following doesn’t hold?
- Minimongo contains a subset of the database’s data
- ReactiveVars are (primarily) for tracking transient client side state (e.g. is the pop out menu panel open or not)
Not really sure where you’re coming from, @t3db0t.
4 Likes
It seems much more clear to me now. I think I was thrown off by some tutorials (or maybe even just one) that seemed to suggest that the ‘normal way to do things’ is to use ReactiveVars in addition to the client db.
Clearly everyone already figured out before me that this is not necessarily necessary. 
Sorry.
Eh well, (and this is just an opinion) it is 