Meteor Helpers caching Cursors

Question

I have a Template that contains a select in it which enables the user to filter through some Objects in a collection that are displayed on a table.

I store the result of the select in a ReactiveVar. I then use this ReactiveVar in the query for a Helper to return my Objects to the Template.

Template Code

<select id="colorSelect">
    <option val="getRed">getRed</option>
    <option val="getBlack">getBlack</option>
</select>

<table>
     {{#each Objects}}
          /* create table */
    {{/each}}
</table>

Here's the JS

//onCreated initializing Template ReactiveVar for Object's Color
Template.Object.onCreated(function() {
    this.color = new ReactiveVar("");
});

//event for changing 'color' based on select option
Template.Object.events({
    'change #colorSelect'(e, template) {
         const target = e.target;
         const color = $(target).val();
         template.color.set(color);
   }
});

//Helper method to return Objects
Template.objects.helpers({
    Objects: function() {
        const color = Template.instance().color.get();
        return Objects.find({foo:bar, color:color}).fetch();
    }
});

This all seems to work just fine and my table adjusts reactively based on the select. My question is about the efficiency and if the framework knows to cache a cursor I've already gotten. So would it literally do a DB.find() everytime the user changes the select?

Is it more efficient to 1. Do one initial find 2. Then filter on this main original data (an array from fetch call) 3. Finally return back to UI However, doing it this way seems to lose any advantage of reactivity altogether and would require rearranging the table with JS.

Or...does Meteor just know to cache cursors I've already gotten (Does it even make a performance difference - seeing as it's taking it from MiniMongo..which afaik is just a JSON object)

Is this pattern of using the reactiveVar in tandem with a Helper the standard?

Answer 1

I'd say your code is pretty solid and this is actually a standard of how it gets done, so no worries about that part.

As for the efficiency and caching, it's important to note that the client already keeps a local copy of the server data, subscriptions, in minimongo , so as long as you:

• keep this data to a minimum; not over publishing
• don't constantly resubscribe to a new data thus destroying old ones

you're good to go. :)