Are Meteor timers obsolete or do I do something wrong?

I have used timers (setInterval/setTimeout) in the server/main.js without knowing that there are Meteor timers. According to the documentation, the native timers shouldn’t work there!? But they do just fine!

These functions work just like their native JavaScript equivalents. If you call the native function, you’ll get an error stating that Meteor code must always run within a Fiber, and advising to use Meteor.bindEnvironment.

Now I am wondering if something changed and the documentation is wrong about this point or should we stick to Meteor Timers anyway? Or do I understand something wrong?

The documentation is correct.

Using the Meteor.setTimeout and Meteor.setInterval is advised, as they do small magic behind the scenes to not have problem with Fibers.

Try using a Meteor feature (I think even try inserting in a collection) and will you have a very nice exception thrown at you.

1 Like

It’s only on the server that this matters and the meteor timers simply wrap the function in bindEnvironment. If you know this it doesn’t matter which approach you take, I prefer to use the non-meteor version and use bindEnvironment if necessary (which certainly isn’t always), but for most it’s likely a safer bet to use the meteor version as you won’t need to worry about fibers.

Quick example:

Meteor.setInterval(function(){
    // Some code
});

Is the same as

setInterval(Meteor.bindEnvironment(function(){
    // Some code
}))
3 Likes

Am I correct that meteor will show an error when bindEnvironment() is not used where it is expected? Therefore, if no error was shown, I don’t have to worry about not using Meteor.setInterval()?

The bindEnvironment error is shown whenever a method needing a fiber is run (like a MongoDB method) and there is no fiber. So, if you don’t see the error, you’re okay.

1 Like