关于javascript:setTimeout〒︿〒-请原谅我一直以来对你的忽视

7次阅读

共计 1503 个字符,预计需要花费 4 分钟才能阅读完成。

纸上得来终觉浅,绝知此事要躬行。哪怕是平时一个不起眼的小常识,咱们也须要以认真的态度去学习,否则,说不定什么时候就会踩到坑,挫伤到彼此!

前戏

不论文章水不水,前戏都必须做足,否则写不上来啊,O(∩_∩)O 哈哈~

之前公布了《前端 JavaScript 之『防抖』的简略代码实现》这篇文章之后,有一位敌人发了这么一条评论:

我在写代码时有一个习惯:就是对曾经销毁的变量顺手赋一个 null,比方这样的:

据说这样销毁的更彻底哦 o(~▽~)d。

针对下面这位敌人的倡议,我也不确定是不是正确,如同平时也的确很少见到在 cleatTimeout 之后再赋值为 null 的操作。

对于不能确定的问题,我只深信一个准则——实际是测验真谛的唯一标准,既然有了困惑,那就入手验证好了。没错,我就是这么间接,请不要诧异!︿(~︶~)︿

意外

原本认为是很简略的一次验证而已,洒洒水啦!可是,谁想却产生了意外,不信你看:

What?! setTimeout 的返回值是一个数字!!就问你:惊不惊喜意不意外?

好歹做了几年开发了,我竟然不晓得这个事,几乎弱爆了!不过话说回来,谁平时会闲着没事去打印它的返回值啊,咱们用的是它的性能好不好。

为什么会呈现这么个后果呢?咱们来看看 MDN 上怎么说:

返回值 timeoutID 是一个正整数,示意定时器的编号。这个值能够传递给 clearTimeout() 来勾销该定时器。

看来这是常识性问题,只怪我平时没留神啊,看来平时要增强基础知识的储备了!

至于为什么 timer 的值始终在减少,MDN 上是这样解释的:

在同一个对象上(一个 window 或者 worker),setTimeout()或者 setInterval() 在后续的调用不会重用同一个定时器编号。然而不同的对象应用独立的编号池。

timer 每次执行的实质是生成了一个新的延时器,属于不同对象,所以编号产生了扭转。

原本还想要再看看 setInterval 的,然而看到这个解释,我就打消了验证的念头,那必然又是一次”惊喜“。

验证

通过了后面这个意外,让我晓得了本人的无知。但意外也是最好的鞭策,即便羞愧,然而结尾所说的验证还是得往下走。

当初咱们晓得了一个真谛:setTimeout 的返回值是一个代表延时器对象惟一身份标识的数字,那么在 clearTimeout() 之后,它的值到底会变成什么呢?请看大屏幕:

咱们看到,在调用 clearTimeout() 办法销毁延时器后,timer 的值并未被清空。

总结

通过下面的验证,咱们能够得出以下论断:

  1. 延时器办法 setTimeout() 的返回值是一个代表定时器惟一身份标识的编号;
  2. 这个编号是定时器毕生成就带的,定时器执行过程中,编号不会发生变化;
  3. 计时器 setInterval 和 延时器 setTimeout 共用一个编号池,且所有编号都不会反复;
  4. 在调用了定时器销毁办法(clearTimeout 和 clearInterval)后,定时器编号不会被清空。

以上总结实用于所有定时器(计时器和延时器)。

嗯,看来我顺手赋一个 null 的做法还是比拟正当的,毕竟是起到了那么一丝丝的作用的(~︶~)↗。

顺手赋 null 是一个好习惯!(~▽~)~*

顺手赋 null 是一个好习惯!(~▽~)~*

顺手赋 null 是一个好习惯!(~▽~)~*

其实,明天这个验证也证实了另一个情理:咱们平时最漠视的,往往是咱们自认为最相熟的,挫伤了对方而不自知!

你品,你细细品!

~

~

~ 本文完,感激浏览!

学习乏味的常识,结识乏味的敌人,塑造乏味的灵魂!

大家好!我是〖编程三昧〗的作者 隐逸王,我的公众号是『编程三昧』,欢送关注,心愿大家多多指教!

常识与技能并重,内力和外功兼修,实践和实际两手都要抓、两手都要硬!

正文完
 0