菜鸟读文档-Vant Weapp-6(小程序中的生命周期-进阶)

正文

在上期中, 我们了解了微信小程序中 Page, 页面内部组件和自定义 tabbar 的生命周期. 但除了这些常见的拥有生命周期的对象外, 微信小程序中还提供了其它更为进阶的拥有生命周期的对象, 且在微信小程序提供的自定义 tabbar 样例中就使用到了这些进阶对象

拥有生命周期的对象-进阶

使用 Component 构造器构造页面

在微信小程序提供的自定义 tabbar 样例中使用到了 Component 构造器来构造页面, 而且我们在教程第4期中对于这一方法有以下发现:

1. Component 构造器将会直接替代先前的 Page 构造器
2. 在 Component 构造器中, 页面生命周期和组件生命周期可以同时使用

接下来我们来测试一下在 Component 构造器中, 同时使用页面生命周期和组件生命周期, 而且在该页面内部设置组件, 分析当页面本身也由 Component 构造时, 页面与页面内部组件生命周期的关系

• 初次载入

  

  相关生命周期顺序总结如下:

  

• 页面路由

  

  相关生命周期顺序总结如下:

  

  

  相关生命周期顺序总结如下:

  

• 重定向

  

  相关生命周期顺序总结如下:

  

从以上实验中我们可以看出:

1. 在 Component 构造器中使用的页面生命周期和页面内部组件的生命周期之间的关系和使用 Page 构造器时一致, 即除了 OnUnload 生命周期外, 页面的生命周期均晚于页面内部组件的生命周期
2. 在 Component 构造器中使用的组件生命周期和页面内部组件的生命周期之间的关系就显得较为复杂了:
   • Component 构造器先于页面内部组件: attached, show, hide
   • 页面内部组件先于 Component 构造器: created, ready, detached

结合上述实验, 我认为, 出于方便记忆, 在使用 Component 构造器构造页面时, 只使用页面生命周期, 不要使用组件生命周期

Component 构造器的优势

看到这, 有的同学可能会有疑问: 如果使用 Component 构造器构造页面时, 只使用页面生命周期, 那为什么不直接使用 Page 构造器呢?

我从微信小程序文档中找到了使用 Component 构造器构造页面的两个优势:

1. 引入组件的属性可以用于接收页面的参数

   • 将跳转页面路径设置为 queryString

     const URL_TO_PAGE4 = "/index/index4/index4?id=4";
     // 注意 wx.switchTab 不支持 queryString
     onTap: function () {
       wx.redirectTo({
         url: URL_TO_PAGE4
       });
     }
     

   • 在目标页面的 Component 构造器中添加对应属性

     // 跳转到该页面后, id 将从 queryString 中直接获取到相应的值
     // 而不需要像 Page 构造器一样在 onLoad 生命周期使用 options 参数
     properties: {
       id: Number
     }
     // 此后的代码段中使用 this.data.id 可以获取到数据4
     

2. 可以使用 behaviors 来提取所有页面中公用的代码段

   首先我们来看一下 behaviors 在微信小程序文档中给的定义

   behaviors 是用于组件间代码共享的特性，类似于一些编程语言中的 “mixins” 或 “traits”。

   每个 behavior 可以包含一组属性、数据、生命周期函数和方法。组件引用它时，它的属性、数据和方法会被合并到组件中，生命周期函数也会在对应时机被调用。 每个组件可以引用多个 behavior ，behavior 也可以引用其它 behavior 。

   可见 behavior 的作用是抽取出共同使用的代码段, 实现代码的复用

   具体的使用详见微信小程序文档 behaviors

预告

从第二期到第六期, 我们花了整整五期的时间来分析研究自定义 tabbar, 在下一期, 我们将结合这一路上所有学习到的知识, 编写出我认为效果最好的自定义 tabbar :)