Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I have seen many stack or google answer, where to delay a function there is a suggestion for timer. But is there a way to delay a function with out using timer. Or other way is there a event where once a event for eg onclick or on blur is done check for the event end and call a function in a lazy manner without using timer.
The only way to delay execution of a function is to do so as a callback in response to something. I believe this pretty much always means you need to have a trigger in the native implementation, as JavaScript is single threaded and will run until it runs out of code to execute.
Typical things that trigger a function call from native code are
Timers firing
Events firing
Async operations completing (eg. Http requests).
Out of these the timer is the only practical one to execute a function later without interactions being required by the user.
So no, not really I'd the short answer.
You can read more about the JavaScript Event Loop at the Mozilla Docs
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I have a JavaScript + HTML program which includes a function taking long time to execute. The problem is, when I run this program on Chrome, Chrome throws unresponsive alert about 20 seconds after the long-time-taking-function starts its process. It is really annoying because I have to click wait button to delete the alert. Is it possible to make the unresponsive alert disabled by changing configuration of Chrome or by inserting some snippet in my JavaScript code?
Any information would be appreciated.
addition
I am sorry for not adding any code. My code is a bit complicated so I don't come up with a minimal reproducible example of my attempt. But I'm trying and please wait for a while.
No, the warning is just telling you that the browser is unresponsive. Disabling the warning wouldn't solve the underlying problem.
If you have long-running scripts (anything over a couple milliseconds should be considered long-running, your 20 second script would definitely be considered long-running), you should use asynchronous techniques: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous
Essentially your code will ask for a 'Promise' which then works in the background without stalling your browser or blocking other code. When it's resolved, the promise will come back to your code and you can use the results.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm creating a Firebase cloud function that routes events to another system by making http calls for every event.
I noticed that if I don't return the promise, the http gets called most of the times (can't be 100% sure). I don't care about the response
Execution time decreases substantially if I don't return it. (155ms vs 13ms)
Does anyone know if a non returned promise is guaranteed to execute?
If your function does not return a Promise, it may be killed prematurely by Cloud Functions.
Also you might come across something like this in your console:
Function execution took 60023 ms, finished with status: 'timeout'
This happens, when a function does not return a Promise to Cloud Functions.
All types of functions except HTTPS type functions require that you return a promise that becomes resolved when asynchronous work is complete. If you don't do this, there is no guarantee that your work will complete, because the Cloud Functions runtime could clean up your function before the work is done.
It doesn't matter if you care about the response or result of the work, you should still be waiting until it's complete before allowing your function to terminate.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am creating an assistant bot in javascript and I want to support reminders, my problem is that it need to support both short timeouts (10 mins) and long timeouts (a month).
To my understanding using the setTimeout() functions wouldn't work for the long timeout, so I thought of using a lookup table and check it every second, but that would be heavy on resources.
I wanted to know if the lookup table it the best option (as far as performance is concerned) and if so whether there are best practices to follow.
I would create a function prepareNextReminders(time_in_minutes, callback) that retrieves reminders in the next X minutes, e.g. one hour. For each of them, creates a setTimeout with the callback and the proper delay and adds the id to a list of prepared reminders.
This function runs every 15 minutes and in each run does the same for the new reminders not already existing in the list of prepared reminders.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Is it possible to implement a function equivalent of setTimeout() in JavaScript? If yes, what would be the best way to do that?
function setTimeout(callback, time_in_ms)
{
// Implementation of time elapse of time_in_ms
callback();
}
I am asking this question out of curiosity. A simple "No, it is not possible" would also be an enough answer to this question.
Can I implement setTimeout() in javascript myself?
No - not without some other natively asynchronous API. You might be able to implement it in terms of setInterval, with web workers, requestAnimationFrame or really anything that runs in the same event loop as setTimeout would. But if there is a reason that prevents you from using the builtin setTimeout, there probably are also other issues with your environment - so it depends on the specific situation.
A synchronous (non-asynchronous) setTimeout equivalent would be something like this:
function myTimeout(fun, milisecs) {
var nowT = Date.now();
while(Date.now()< nowT+milisecs){
continue;
}
fun();
}
function consout() {
console.log('The future arrived now!');
}
myTimeout(consout,2000);
However, as Bergi mentioned you probably want an asynchronous API to avoid stalling the JavaScript execution of your browser.
A Worker has multi-thread capabilities to allow this, with functions such as myWorker.port.start() and myWorker.terminate()... I have never needed to create something with Workers or similar APIs, but perhaps you may research a little bit more in this field (I also should not complete your homework, if that is the case).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have a javascript jquery function which I need to use twice, in 2 different files.
Now, the question is, which is the better way to implement it, performance-wise. Should I declare function global using 'window' variable, or should I declare the function in each of the files?
Please keep in mind that traffic is not an issue, the script will be used from the hard-drive.
Thanks for your help.
My answer follows the DRY Principle (Don't Repeat Yourself). If you put the function in both files, and later find a bug on Page #1, someone has to remember that the function is duplicated on Page #2 as well (in this case, assume the bug report says "Page #1 doesn't work properly"). From that bug report, would the developer know to also modify Page #2? To avoid the human error piece, I'd always recommend you don't copy/paste functions into multiple locations.
Performance wise, if you're not concerned about traffic, the difference is nanoseconds slower wrapping it in a shared function as you do have to create an additional stack frame for the shared function call that in turn calls jQuery, but we're really talking nanoseconds. For a few nanoseconds lost, I'd say DRY is the way to go.