setInterval/setTimeout override?

[Miro]

From the [docs](http://docs.meteor.com/#timers):

Meteor.setTimeout() & Meteor.setInterval() "...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...".

Meteor is doing an override on the native functions to throw an error.

In some applications I've used (and had problems) with third party libraries (client side) that are using the native functions, totally out of one's control.

I'm wondering if it would be wise to do the opposite - ie. not throwing an error but instead invoke the Meteor.setTimeout()/Meteor.setInterval() by overriding the "native" JavaScript functions, at least on the client side.

What are implications of doing so and why Meteor didn't do it that way?

One problem would be, if done from the package, the loading order of packages - the packages loaded before the overriding package would still access the "native" functions (though overridden by Meteor)...

Miro

[Slava Kim]

Hi,

Meteor doesn't override native setTimeout and setInterval. It is Meteor-specific code that requires additional environment and Fibers. So in reality, it is Meteor.setInterval and Meteor.setTimeout those wrap native versions and set the required environment before the callback execution.

To resolve your problems with 3rd party libraries, you can wrap your callbacks into Meteor.bindEnvironment or use Meteor._wrapAsync to make functions look like synchronous on the server side.

See these StackOverflow questions for more information: http://stackoverflow.com/a/18541825/1626821, http://stackoverflow.com/questions/18346847/future-wait-cant-wait-without-a-fiber-while-waiting-on-another-future-in-met/18347076#18347076

Also see these videos on EventedMind if you are interested why it happens or want more insight on what is happening behind the scenes: 

https://www.eventedmind.com/tracks/feed-archive/meteor-dynamic-scoping-with-environment-variables

https://www.eventedmind.com/tracks/feed-archive/meteor-what-is-meteor-bindenvironment

https://www.eventedmind.com/tracks/feed-archive/meteor-meteor-wrapasync

Slava

[Miro]

Hi,

Thank you for your answer.

I'm well aware of the Fibers/bidEnvironment/_wrapAsinc but I was referring to the client side of things - 3rd party javascript libraries using native functions and messing up the UX.

Miro

[Slava Kim]

Hi,

I don't really understand how 3rd party javascript libraries can mess up the UX if they use native timeouts. Meteor doesn't change native timeout.

Maybe direct links to code will give you more information on how to deal with issues you have in your app:

https://github.com/meteor/meteor/blob/b5cd66dedd014a8df7990f9160284c78103ef955/packages/meteor/timers.js#L21 - Meteor.setInterval is set here

https://github.com/meteor/meteor/blob/b5cd66dedd014a8df7990f9160284c78103ef955/packages/meteor/dynamics_browser.js#L27 - bindEnvironment on the client is mostly error handling

[David Glasser]

As an analogy, pretend we had this code:

var safe = false;

var functionThatMustBeCalledSafely = function () {
if (!safe)
throw Error("It's not safe!");
...
};

Meteor.setTimeout = function (f, time) {
setTimeout(function () {
safe = true;
try {
f();
} finally {
safe = false;
}
}, time);
});

If you call setTimeout(functionThatMustBeCalledSafely, 100), then
functionThatMustBeCalledSafely will throw an error... because we
*DON'T* override setTimeout. Using Meteor.setTimeout, things work
properly.

In the actual case, "being called safely" means "being called in the
context of a Fiber", and functionThatMustBeCalledSafely is any
function that needs to block (yield) on IO, such as reading from a
database.

> --
> You received this message because you are subscribed to the Google Groups
> "meteor-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to meteor-talk...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Miro]

Hi,

I might have been a bit too general in my question and maybe sent discussion in a wrong direction, so let me explain:

I have a Bootstrap 3 modal that closes immediately after opening at page load. I have tried many advices, but besides them being "hacky", I'm still losing modal in about 3 out of 10 cases.

Now, I'm not saying that I've done everything possible to make it happen - I'm just wondering why do I have to hack around to open a darn modal (and keep it open) at all?

While trying to crush that bug, I came to a conclusion(?) that it must be Bootstrap's native setInterval/setTimeout functions firing at will - out of sync with Meteor.

So, my question was regarding the possibility of circumventing or avoiding those problems by "overriding" the native functions with Meteor.setInterval/Meteor.setTimeout.

Does that make any sense?

Miro