Is it true that if possible I should never use setInterval & setTimeout?

后端 未结 3 2020
花落未央
花落未央 2021-02-09 10:54

I am learning to code in JavaScript. I am programming something with some timed mouse animation. I\'m just about to add some code which draws the mouse path.

It\'s going

相关标签:
3条回答
  • 2021-02-09 11:34

    I don't think using setInterval or setTimeout is bad practice. Using setTimeout is bad practice when you want to do something in future but you don't exactly know when you will be able to do that. For example this is bad practice:

    makeHeavyDomMovements();
    setTimeout(function () {
      //with 3000 timeout I'm sure any device has made my changes
      makeNextMove();
    }, 3000);
    

    the correct way was:

    makeHeavyDomMovements().
    then(function () {
       makeNextMove();
    });
    

    If you want to do something in future like respond to a user action 100ms later, it's best practice to use setTimeout or if you want to put something in browser queue, you should use setTimeout (or use a worker if needed).

    It's the same as setInterval, if you are using to do something that should be done every x milliseconds, well you are using it correctly and it's not bad practice, here is a bad usage of setInterval:

    var dbInterval = setInterval(function () {
      if (dbIsReady()) {
        clearInterval(dbInterval);
        fireReadyEvent();
      }
    }, 300);
    

    And here is a regular usage of setInterval:

    setInterval(function () {
      runSync();
    }, 600000);
    

    Bad practices and good practices are defied by the way you use your environment tools not those tools themselves.

    0 讨论(0)
  • 2021-02-09 11:41

    Luz Caballero does a fair job of describing why rAF is a useful replacement for setInterval:

    https://dev.opera.com/articles/better-performance-with-requestanimationframe/.

    As for me, I now use rAF instead of setInterval because rAF has some built-in usefulness that would require additional coding with setInterval:

    • rAF will attempt to synchronize its calls with the display refresh cycle. This gives the code in the loop the "best chance" to complete between the refresh cycles.

    • If the tasks in loop#1 can't complete before loop#2 is requested, then the new loop#2 won't be called until the incomplete loop#1 is completed. This means the browser won't be overworked with a backlog of accumulated loops.

    • If the user switches to a different browser tab then loops in the current tab are suspended. This allows processing power to shift to the new tab instead of being used in the now invisible loop tap. This is also a power-saving feature on battery powered devices. If you want the loop to continue processing while a tab is unfocused you must use setInterval.

    • The rAF callback function automatically gets a high-precision timestamp argument. This allows rAF loops to calculate & use elapsed times. This elaped time can be used to (1) delay until a specified elapsed time has occurred or (2) "catch up" on time based tasks that were desired but were unable to be completed.

    0 讨论(0)
  • 2021-02-09 11:48

    you can use them if you are 100% sure that it is the exact time you need you. if it is an ambiguous situation then not to use it. if you are using a javascript framework look for a lifecycle hooks e.g in angular use Angular life cycle hooks.

    0 讨论(0)
提交回复
热议问题