I have a slider (range input) that updates data via its ‘input’ callback for continuous updates as the user moves the slider. The input callback calls a Meteor method.
I do not want to call the server’s method for these continuous updates to the database for obvious reasons. 
I’d only like to call the server’s implementation of the method on the ‘change’ event (when the user is done sliding).
Any suggestions on how I can only call the stub/client version if I want to? Thanks!
Then modify the input callback, call method only when you need.
onChange={this.foo()} where foo() is a wrapper to your method call.
Sorry, I don’t think I was clear.
User input → meteor method → updates collection → causes reactive UI update
The meteor method is implemented on both client and server, but I’d love to sometimes be able to update the collection on the client only (stub) while, for example, the user is dragging a slider. I don’t want to call the server 100 times, I just want to update the data until they mouseup, THEN I call the server+stub, rather than just the stub.
Does that make sense?
Dropping some red pills today damn bro w00t
myCollection.update({match}, {$set: {foo: bar}});
Holy moly
Wait, what? If a collection is published from the server, you definitely do not want to call update on the client outside of a method stub – that is, if you’re following the strongly advised Meteor security pattern for collection updates/inserts/removes, which suggests deny for all collection methods:
MyCollection.deny({
insert: () => true,
update: () => true,
remove: () => true,
})
I’m asking specifically if it’s possible to call a stub only. I’m not interested in other solutions here. Thanks.
Don’t worry, if you removed the insecure package then you don’t have to worry. There isn’t any difference if you update the local data via method call or just update them directly. Data is data and you should not believe anything the client sent to the server. They can fake everything, they can even do it without the Meteor on the client.
I don’t know what is your view layer, in questions like this it would be good to know.
In principle, input types should be managed by local states and not directly by values from DB.
I’d do it in two ways depending on the UX required. If the user has to save the form from a Save button, I’d keep the slider state in the local state of the view. If however, you need an imediate input in the DB once the slider is set to the final destination, you can use the ‘mouseup’ event to trigger the saving of the selected value (from the local state) to DB.
This sounds like a perfect place for _.debounce(). This from the underscore docs:
Useful for implementing behavior that should only happen after the input has stopped arriving. For example: rendering a preview of a Markdown comment, recalculating a layout after the window has stopped being resized, and so on.
Try wrapping your meteor method call with debounce(), and use the generated function as the callback in the UI widget. That way it’ll only call the method only once the user has stopped (or paused) moving the slider.
It’s not exactly the same as only calling the stub on the client, but it takes care of all the logic that you’d have to write yourself if you were able to call only the stub.