前言

从小程序的发布，到现在已经有一年多的时间了，从当时信誓旦旦的要替代APP，到近期实现了APP和小程序互跳的功能，定位也悄然变为APP的一个补充，都是现实给逼的，就像当时卸载了摩拜和美团的APP，觉得只用小程序就行的同事，最后都又把APP装了回来，为什么呢？因为小程序只是实现了原有APP的部分功能，最后发现还是APP用着方便，毕竟现在手机内存基本都是32g起，一个APP也占不了多少地方。

技术无止境，人生莫等闲，开启正文。

技术栈

微信小程序官方文档已经很详细了，经过多次的更新，目前小程序已经支持自定义组件，引入其他开发者的插件和外部的资源，还有了一套小程序的语言wxs,据官方文档的说法在IOS上的运行速度比JavaScript要快2~20倍，组件和API也是越来越完善。

WePY是腾讯一团队出的一个小程序组件化开发框架，第一次更新是在2016.11.23，比小程序的发布时间2017.1.9还早，也就是说小程序在腾讯内测的时候，某个喜欢Vue大佬用了之后，发现这玩意开发起来不够爽呀，连组件都不支持，然后这个大佬就拉了一帮人，说兄弟们咱弄个框架出来吧，让大家能用类Vue的开发方式去开发小程序，然后你应该懂了，如果你会Vue，上手这个那是分分钟的事，它支持组件 Props 传值，自定义事件、组件分布式复用Mixin、计算属性函数computed、模板内容分发slot等等。

weappx是一个小程序的状态管理框架，wepy和原生小程序都可以使用， API和Dva，Vuex挺像，但是比它们两个要简单的多，Dva已经把APi的数量精简到6个，它更狠才4个API就能上手，API虽然少但作为状态管理框架，该有的功能都是有的，开发起来还是相当的爽的，详细的介绍请看文档，相比Dva现在的9000多个star，weappx的50多个star显的有点寒酸，如果用了之后觉得挺不错的童鞋，都star下，精神上支持下作者。

遇到的坑以及开发注意点

1. repeat标签嵌套两级以及以上组件传值给自组件传值问题

这个问题其实是wepy的一个bug，在github上已经有好多人提过Issues，官方并没有给出解释，经过自己的摸索，有两种解决方式：

对于纯组件用小程序原生的模板template代替

子组件中第二层循环采用此写法，直接使用template

<template wx:key="{{index}}" wx:for="{{item.giftBoxs}}" wx:for-item="giftBoxsItem" data="{{...giftBoxsItem}}" is="indexMoItem"></template>

在主页面中引入此模板

<import src="../../components/giftIndex/indexMoItem.wxml"/>

wepy最终会把所引用的组件代码，都打包到一个主页面中的,所以在主页面引入模板即可

第一种方法可以解决这个问题，并且还节省了代码量，但这属于wepy和原生小程序混写，后面又发现另一种解决办法

对于第二层循环要传的值，用repeat标签包裹一层

<repeat for="{{ [item] }}" key="item.orderNo" index="index" item="itemval"> <giftItem :itemval="itemval" ></giftItem> </repeat>

已经在wepy的Issues中做了回答，并有一个老铁点了赞，应该是帮他解决了这个问题

2. 向子组件传类似Object.key这样的值

正常传值

// 数据
 data = {
    textMsg1: 'text1',
    textMsg2: {
      text: 'text2'
    },
  }
 // 组件
<child :msg="textMsg1"></child>

界面展示

传对象中的值

<child :msg="textMsg2.text"></child>

界面展示

没有报错但是值也无法传递，这个问题也是Issues中提的比较多的,可采用下面方法解决

<repeat for="{{ [textMsg2.text] }}">
   <child :msg="item"></child>
</repeat>

3. 小程序开发工具变慢

在开发过程城中，随着项目文件的越来越大，会发现小程序的开发工具越来越慢，甚至一个跳转都要等几秒钟才能跳转过去，这个时候需要把小程序打包出来的文件dist文件夹删掉，然后重新打包，会快很多，wepy也提供了命令，直接运行 npm run clean 也能达到同样的效果。

4. 小程序在手机上预览，出现卡顿现象

出现这种情况有多方面的原因，如果你之前用过原生小程序开发过项目，那么直接点击开发工具上的预览按钮，然后用手机扫码预览是一个常见的操作，但是在使用wepy过程中，你使用npm run dev 命令后，是出于开发环境，dist文件夹中的代码并没有进行压缩，优化，所以手机预览的时候会显得很慢，运行 npm run build打成生产包预览，可以解决。

5. 数据更新了，UI视图没有更新

这个也与开发环境和生成环境有关系，这种情况出现的比较少，在开发选择地址模块的时候，在开发工具上选择地址后，并改变了model中的数据，但是视图并没有更新，这种现象只在开发环境中出现，生产环境一切正常。

6. 个别手机样式错乱

出现这种问题，是因为wepy脚手架中并没有配置样式自动补全，需要自己手动配置，在wepy.config.js添加下面代码即可，插件地址

module.exports.plugins = {
    'autoprefixer': {
      filter: /\.wxss$/,
      config: {
        browsers: ['last 11 iOS versions']
      }
    }
  }

7. 通一个页面多次使用同一个组件数据传递问题

同一个页面多次使用同一个组件，要为这个组件起不同的名字，这个官方文档有介绍，

需要注意的是，WePY中的组件都是静态组件，是以组件ID作为唯一标识的，每一个ID都对应一个组件实例，当页面引入两个相同ID的组件时，这两个组件共用同一个实例与数据，当其中一个组件数据变化时，另外一个也会一起变化。

这个与wepy的组件机制有关，

// data
data = {
    textMsg1: 'text1',
    textMsg3: 'text3',
    textMsg2: {
      text: 'text2'
    },
}
// 组件
 <child :msg="textMsg1"></child>
 <child :msg="textMsg3"></child>

按照正常的逻辑，最终显示结果肯定是text1和text3,但是

我们查看编译后的代码

 <view class="containers">
    <view>我是子组件</view>
    传递来的数据：{{$child$msg}}
</view>
<view class="containers">
 <view>我是子组件</view>
  传递来的数据：{{$child$msg}}
</view>

在开发工具中的AppData中我们能看到

相信大家已经明白了，wepy中的组件其实就是把组件中的代码copy到引入的页面中，组件中使用的变量，名字被改成$+组件名字+变量名字，在组件引用页中的data其实就是一个对象，对象的属性值，后面会覆盖前面，页面渲染过程，大致如下

data = {
}
// 渲染第一个组件
data.$child$msg = 'text1'
// 渲染第二个组件
data.$child$msg = 'text3'

将第二个组件注释掉，第一个就会显示正常

我们给组件起不同的名字后显示就能如预期那样渲染

// 挂载组件
components = {
    child1: Child,
    child2: Child
};

<child1 :msg="textMsg1"></child1>
<child2 :msg="textMsg3"></child2>

// 编译后
<view class="containers">
 <view>我是子组件</view>
  传递来的数据：{{$child1$msg}}
</view>
<view class="containers">
 <view>我是子组件</view>
  传递来的数据：{{$child2$msg}}
</view>

我们可以看到显示正常了，查看data也会看到

8. weappx中更改state数据报错

在使用weappx过程中，只能在mutations中更改state中的数据，如果在其他地方更改数据就会报错，Uncaught (in promise) TypeError: Cannot assign to read only property 'count' of object '#'，这句话的意思是，count为只读属性，不能进行设置，如果一个页面要使用其他model中的数据，最好是深度clone一份，以免无意中修改数据，出现上述错误

使用感受

1.采用类Vue语法，对于新手比较友好，上手比较快, 但还需要学习小程序的api，框架不是很完善，有不少坑要填

2.使用状态管理框架,集中管理逻辑代码，实现不同页面状态的共享，提升开发效率

3.代码结构清晰，接口，逻辑代码和静态页面分离，便于多人合作和后期的维护

4.引入库比较多，导致项目体积过大

总结

总的来说，如果项目比较简单，不建议采用，直接采用原生小程序去开发效率反而更高；如果项目较大时间又比较近，需要多人合作，可采用此框架，开发效率还是比较高的，质量也是可以的；如果时间充足对质量也要求比较高，那还是采用原生小程序去开发，现在小程序已经比较完善了，没必要再用第三方的框架去开发。