阅读 1696

wepy+weappx开发小程序遇到的坑以及解决方案

前言

从小程序的发布,到现在已经有一年多的时间了,从当时信誓旦旦的要替代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,官方并没有给出解释,经过自己的摸索,有两种解决方式:

  1. 对于纯组件用小程序原生的模板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最终会把所引用的组件代码,都打包到一个主页面中的,所以在主页面引入模板即可

  1. 第一种方法可以解决这个问题,并且还节省了代码量,但这属于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.引入库比较多,导致项目体积过大

总结

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

关注下面的标签,发现更多相似文章
评论