elementui tabs 在页面销毁时候 vue离开页面销毁事件

描述：
在vue中，我在某个页面加载后，开启了一个定时器，但是当我，通过路由，离开页面后，我进行了销毁组件停止计时器 的操作，乍一看，这样的操作没有任何问题，但是当我去到新页面后，计时器却依然在调用，解决了很久，才发现问题所在并解决！

解决前有问题的代码

mounted() {
   this.timer = setInterval(() => {   // 在页面加载后开启一个定时器
      this.totalreq();        
      console.log("定时器调用");
    }, 5000)
  },

  methods: {
   cliak(){
    this.$destroy()  //触发beforeDestroy 钩子函数
      this.$router.push({
        path: "/staff",
      });
   }
}
  beforeDestroy() {
    clearInterval（this.timer）   //结束定时器，
    console.log(this.timer, "销毁组件");
  }

解决

采用监听事件 vm.$once

问题原因是 setInterval 计时器本身是由全局window 调用，所以 计时器的事件 不能绑定在 组件的的 this 身上，只能 绑定在 普通变量身上

 

mounted() {
    this.totalreq();
    const timer = setInterval(() => {     //绑定在 const 普通变量身上，不要绑定在 this上
      this.totalreq();
      console.log("继续调用");
    }, 5000)
    this.$once('hook:beforeDestroy', () => {   //再通过事件监听，监听到 组件销毁 后，再执行关闭计时器。
      clearInterval(timer);
    })
  },

vue离开页面销毁定时器

beforeDestroy() {
if(this.timer) {
　　　　clearInterval(this.timer); //关闭
　　 }  //利用vue的生命周期函数

vue 是单页面应用，路由切换后，定时器并不会自动关闭，需要手动清除，当页面被销毁时，清除定时器即可。

组件里定时器销毁问题

我在a页面写一个定时，让他每秒钟打印一个1，然后跳转到b页面，此时可以看到，定时器依然在执行。这样是非常消耗性能的。

如下图所示

 

解决方法1 

首先我在data函数里面进行定义定时器名称：

data() {                   
   return {                                          
    timer: null  // 定时器名称                 
   }         
 },

然后这样使用定时器：

this.timer = (() => {     // 某些操作 }, 1000)

最后在beforeDestroy()生命周期内清除定时器：

beforeDestroy() {        

  clearInterval(this.timer);                

  this.timer = null;

}

 

方案1有两点不好的地方，引用尤大的话来说就是：

• 它需要在这个组件实例中保存这个 timer，如果可以的话最好只有生命周期钩子可以访问到它。这并不算严重的问题，但是它可以被视为杂物。
• 我们的建立代码独立于我们的清理代码，这使得我们比较难于程序化的清理我们建立的所有东西。

解决方案2

该方法是通过$once这个事件侦听器器在定义完定时器之后的位置来清除定时器。

以下是完整代码：

const timer = setInterval(() =>{ // 某些定时器操作   }, 500);            
// 通过$once来监听定时器，在beforeDestroy钩子可以被清除。 
this.$once('hook:beforeDestroy', () => {                     
        clearInterval(timer);                                     
})

类似于其他需要在当前页面使用，离开需要销毁的组件（例如一些第三方库的picker组件等等），都可以使用此方式来解决离开后以后在背后运行的问题。

综合来说，我们更推荐使用方案2，使得代码可读性更强，一目了然。