导语: 从接触小程序开始,到现在大大小小做了差不多有五六个小程序项目了,小项目的只有几个页面,大的项目有几十个页面。此篇文章是对之前...
从接触小程序开始,到现在大大小小做了差不多有五六个小程序项目了,小项目的只有几个页面,大的项目有几十个页面。此篇文章是对之前项目的一个总结,项目的脚手架,开发框架和后期的优化是一个逐渐进化完善的过程,如果你打算开发小程序或者已经在开发小程序,相信这些经验对你会有一定的帮助。 脚手架小程序开发者工具可以直接编写小程序的,但是开发工具就像武士手中的剑,多年磨炼,已经达到人剑合一了,突然换把武器,那势必影响杀敌效率,所以使用自己熟悉的开发工具还是很有必要的。 本人所在的公司基本都是中小型公司,项目开发周期都很短,前期的准备工作最多也就几天时间,所以自己去撸一套脚手架然后用于项目开发,难度比较大,在网上找优质的资源是最好的选择。 大佬justjavac的开源项目 微信小程序开发资源汇总 ,涵盖了大量的优质小程序开发资源,在此推荐一波。 当然,脚手架的选择也是视项目而定的,如果只有几个页面的项目,搞一套很重的工具未免有点画蛇添足了。我们的做法是小项目,直接撸,大点的项目选用网络上的优质资源+自己改写。
详细介绍请点击WePY文档进行查看,后续框架选择上也会提到,差点被这框架害惨了。
项目的地址为 weapp-start ,其中 weapp-plugin-require(分析依赖,导入第三方 npm) ,存在问题,window操作系统会出现路径错误,我已修复,并给作者提了PR,但作者并没有修复这个问题,如果有同学要用到这个脚手架,请下载我修改好的文件进行替换, 下载地址 。 另推荐我根据weapp-start搭建的环境,目录结构为:
├── README.md // 说明文档
├── dist // 编译后的代码,用小程序开发工具打开此文件夹
├── mock.js // 模拟数据的文件
├── package-lock.json
├── package.json
├── project.config.json // 项目配置文件
├── src // 项目代码都在这个文件夹下
│ ├── app.js // 等同于小程序根目录下的app.js
│ ├── app.json // 等同于小程序根目录下的app.json
│ ├── app.wxss // 等同于小程序根目录下的app.wxss
│ ├── assets // 项目中使用到的静态资源
│ │ └── images
│ │ ├── example
│ │ └── tab
│ ├── components // 公用的组件
│ ├── page // 存放小程序的各个页面文件
│ │ ├── example // example 页面
│ │ │ ├── components // example页面中的组件
│ │ │ ├── index.js
│ │ │ ├── index.json
│ │ │ ├── index.wxml
│ │ │ ├── index.wxss
│ │ │ ├── services // example页面中接口
│ │ │ ├── template // example页面中的模板
│ │ │ └── wxs // example页面中的wxs文件
│ │ ├── globalStore.js // 全局共享的数据
│ │ └── test
│ │ ├── index.js
│ │ ├── index.json
│ │ ├── index.wxml
│ │ └── index.wxss
│ ├── template // 公用的模板
│ └── utils // 公用的方法或工具
│ ├── config.js // 全局的一些配置信息
│ ├── create.js // 状态管理插件
│ ├── mitt.js // 状态管理插件
│ ├── obaa.js // 状态管理插件
│ ├── util.js // 公用方法
│ ├── wxRequest.js // 封装的小程序请求数据方法
│ └── wxapi.js // 对小程序api进行Promise封装
└── weapp.config.js // 对脚手架的配置文件
复制代码
项目地址为 点击查看 ,觉得有用的请Star或者fork哟。 当然,网上也有很多优秀的脚手架,大家可以根据自己的需要选择哟。 小程序开发框架17年的项目并没有使用开源的框架,直接使用原生小程序写的,开发过程印象中并没有很多的坑,只记得当时用到了一个富文本的插件, wxParse ,现在已5000多个Star了,虽然现在小程序有了富文本组件 rich-text ,但在最近的项目中还是用了这个插件,因为后端的兄弟说,他们不能将html转成 rich-text 需要的数据格式,后端是java的,有使用这个组件的同学,麻烦下面留个言,我要去鄙视后端一下。 前文提到自己在项目开发过程中使用过WePY框架,那么下面我就简单列一下现在比较火热的三大小程序框架WePY,mpvue和Taro的特性,然后着重说下WePY:
上文已列出,此处不再赘述 三大框架分别是国内三家大佬的前端团队产物,印象中mpvue和taro都是18年下半年出来的,WePY出来的最早,几乎和小程序同步。 mpvue拥抱了vue,taro拥抱了react,WePY握住了vue的手,mpvue和taro都没有用过,我们只是开发个小程序,不用做到H5和RN共用一套代码,所以18年中开发的一个电商小程序选择了WePY,毕竟腾讯的产物,亲儿子。 后来了解到,是腾讯的儿子没错,不过是养子,WePY本来是腾讯内部一员工的个人项目,后来腾讯团队看这个项目不错,就由官方来维护了,由此带来了一些问题,曾在掘金看到过对WePY作者的专访(好像是专访,文章我找不到了),作者自己也承认,WePY前期的一些核心代码存在的缺陷,后期很难修复了,像脏检查机制,据说2.0会有很大的改变。 贴一张WePY其中的一个 Issue ,我们当时的心情和他是一样一样的,不过我们不用重构了,项目死掉了,哈哈哈哈(悲凉的笑) 自己曾经写过一篇 wepy+weappx开发小程序遇到的坑以及解决方案 ,文中列举了开发过程中遇到的一些问题和解决方式,在此就不赘述了,想了解的同学可以点击查看。 如果你要问我开发小程序选择那个框架合适?我只能给出一个建议,根据需求来定,如果只是单纯的想做个小程序,就不要用框架了,小程序的语法目前已经很完善了,何必要去学习两套语法呢,出了问题,又改不动他们框架,一句话概括下就是, 小程序原生有的问题他们肯定有,原生没的问题,他们可能给你造出来 。 当然,如果有写一套代码适用H5和RN,那么可以考虑下mpvue和taro,作者更新很频繁,有团队维护,至于能不能提高效率,还得看需求,我们现在是不会选用任何框架了,小程序已经玩的很熟,没必要再折腾了。 小程序开发建议在开发过程中,我们总结了一些感觉比较好的开发实践,在此奉献一波,大佬别笑哈。
上文中脚手架第三项中贴出的目录结构,是目前我们觉得比较好的一种形式(参照umi项目的建议),按页面组织代码,将一个页面所需要的内容放在同一个文件夹,方便日后的维护和有类似页面开发时候的复制,存在公用组件的时候,放到外部的文件夹中,当一个项目大了以后,这种目录结构,真的很方便。
组件的层级真的不能太深,2层最好,不能超过3层,之前项目有的封装组件过度,层级太深,后期维护,根据数据传递一层层的去找代码,简直不要太爽(反话)。
目前小程序能用的状态管理框架也是比较多的,Redux,Mobx,还有基于Redux二次开发的像weappx,都很好,在这推荐两个自己用过和打算用的,使用过的 weappx ,打算用的 omi-mp-create ,项目比较小可以不用,大项目还是用上吧,都放到global中,不好维护。
电商项目中,少不了类似倒计时这种功能的,像这种需要频繁setData操作的功能,应该单独放到一个组件中,为啥呢?当你setData的时候,小程序会有一个遍历监听了data数据方法的过程,比如当你setData的时候,小程序wxs中的函数都会执行,在我上文提到自己的脚手架中有这个例子 weapp-quick-start ,感兴趣的可以测试一下。
小程序对js表达式的支持并不是很好,当然,就算可以,我也曾见过这样的代码 <block wx:if="{{drawgift.giftDetail.virtualGoods.length>1||((drawgift.giftDetail.realGoods.length>0||drawgift.giftDetail.couponGoods.length>0)&&drawgift.giftDetail.virtualGoods.length>0)}}"> 复制代码
把这些判断的逻辑放到wxs中,统一维护岂不是美哉。还有一点,官方说在 iOS 设备上小程序内的 wxs 会比 javascript 代码快 2 ~ 20 倍,所以,能用还是要用起来的。
不用的包,别偷懒,统统删掉,至于分包加载等,推荐看下这篇文章,我就不啰嗦了 微信小程序:一些运行细节及针对性的优化策略 |
温馨提示:这篇文章没有解决您的问题?欢迎添加微信:18948083295,有微信小程序专业人员,保证有问必答。转载本站文章请注明转自http://www.okeydown.com/(微信小程序网)。