本文主要是从代码方面跟大家分享我自己在开发小程序的一些做法,希望能帮到一些同学。
前言
不知道大家有没有这种体会,刚到公司时,领导要你维护之前别人写的代码,你看着别人写的代码陷入了深深的思考:“这谁写的代码,这么残忍”
俗话说“不怕自己写代码,就怕改别人的代码”,一言不和就改到你吐血,所以为了别人好,也为了自己好,代码规范,从我做起。
项目目录结构
在开发之前,首先要明确你要做什么,不要一上来就是干,咱们先把项目结构搭好。一般来说,开发工具初始化的项目基本可以满足需求,如果你的项目比较复杂又有一定的结构的话就要考虑分好目录结构了,我的做法如下图:
- component文件夹是放自定义组件的
- pages放页面
- public放公共资源如样式表和公共图标
- units放各种公共api文件和封装的一些js文件
- config.js是配置文件
这么分已经足以满足我的需求,你可以根据自己的项目灵活拆分。
配置文件
我的项目中有个config.js,这个文件是用来配置项目中要用到的一些接口和其它私有字段,我们知道在开发时通常会有测试环境和正式环境,而测试环境跟正式环境的域名可能会不一样,如果不做好配置的话直接写死接口那等到上线的时候一个个改会非常麻烦,所以做好配置是必需的,文件大致如下:
首先是定义域名,然后在config对象里定义接口名称,getAPI(key)是获取接口方法,最后通过module暴露出去就可以了.引用的时候只要在页面引入 import domain from ‘…/…/config’;,然后wx.request的时候url的获取方式是domain.getAPI(’’)
代码健壮性、容错性
例子
代码的健壮性、容错性也是我们应该要考虑的一点,移动端的项目不像pc端的网络那么稳定,很多时候网络一不稳定就决定我们的项目是否能正常运行,而一个好的项目就一定要有良好的容错性,就是说在网络异常或其它因素导致我们的项目不能运行时程序要有一个友好的反馈,下面是一个网络请求的例子:
相信多数人请求的方式是这样,包括我以前刚接触小程序的时候也是这样写,这样写不是说不好,而是不太严谨,如果能够正常获取数据那还好,但是一旦请求出现错误那程序可以到此就没法运行下去了,有些比较好的会加上faill失败回调,但也只是请求失败时的判断,在请求成功到获取数据的这段流程内其实是还有一些需要我们判断的,一般我的做法是这样:
在请求成功后小程序会进行如下判断:
- 判断是否返回200,是则进行一下步操作,否则抛出错误
- 判断数据结构是否完整,是则进行一下步操作,否则抛出错误
然后就可以在页面根据情况进行相应的操作了。
定制错误提示码
可以看到上面的截图的错误打印后面会带一个gde0或gde1的英文代码,这个代码是干嘛用的呢,其实是用来报障的,当我们的小程序上线后可能会遇到一些用户发来的报障,一般是通过截图发给我们,之前没有做错误提示码的时候可能只是根据一句错误提示来定位错误,但是很多时候误提示语都是一样的,我们根本不知道是哪里错了,这样一来就不能很快的定位的错误,所以加上这样一个提示码,到时用户一发截图来,我们只要根据这个错误码就能很快的定位错误并解决了,错误提示码建议命名如下:
- 不宜过长,3个字母左右
- 唯一性
- 意义明确
像上面gde表示获取草稿失败,后面加上数字表示是哪一步出错。
模块化
我们组内的大神说过, 模块化的意义在义分治,不在于复用。
之前我以为模块化只是为了可以复用,其实不然,无论模块多么小也是可以模块化,哪怕只是一个简单的样式也一样,并是不为了复用,而是管理起来方便。
很多同学经常将一些公共的样式事js放在app.wxss和app.js里以便调用,这样做其实有一个坏处,就是维护性比较差,如果是比较小的项目还好,项目一大问题就来了。而且项目是会迭代的,不可能总是一个人开发,可能后面会交接给其他人开发,所以会造成的问题就是:
- app.wxss和app.js里的内容只会越来越多,因为别人不确定哪些是没用的也不敢删,只能往里加东西,造成文件臃肿,不利于维护。
- app.wxss和app.js对于每个页面都有效,可读性方面比较差。
所以模块化的意义就出来了,将公共的部分进行模块化统一管理,也便于维护。
样式模块化
公共样式根据上面的目录结构我是放在public里的css里,每个文件命名好说明是哪个部分的模块化,比如下面这个就表示一个按钮的模块化
前面说过模块化不在于大小,就算只是一个简单的样式也可以进行模块化,只要在用到的地方import一下就行了,就知道哪里有用到,哪里没有用到,清晰明了。
js模块化
js模块化这里分为两个部分的模块化,一部分是公共js的模块化,另一部分是页面js的模块化即业务与数据的拆分。
公共js模块化
比较常用的公共js有微信登录,弹窗,请求等,一般我是放在units文件夹里,这里经微信弹窗api为例:
如图是在小程序中经常会用到的弹窗提示,这里进行封装,定义变量,只要在页面中引入就能直接调用了,不用每次都写一大串。比如在请求的时候是这样用的
toast()就是封装的弹窗api,这样看起来是不是清爽多了!
业务与数据模块化
业务与数据模块化就是指业务和数据分开,互不影响,业务只负责业务,数据只负责数据,可以看到页面会比普通的页面多了一个api.js
这个文件主要就是用来获取数据的,而index.js主要用来处理数据,这样分工明确,相比以往获取数据和处理数据都在一个页面要好很多,而且我这里获取数据是返回一个promise对象的,也方便处理一些异步操作。
组件化
组件化相信大家都不陌生了,自从小程序支持自定义组件,可以说是大大地提高了开发效率,我们可以将一些公共的部分进行组件化,这部分就不详细介绍,大家可以去看文档。组件化对于我们的项目来说有很大的好处,而且组件化的可移植性强,从一个项目复用到另一个项目基本不需要做什么改动。
总结
这篇文章通过我自己的一些经验来给大家介绍如何优化自己的代码,主要有以下几点
- 分好项目目录结构
- 做好接口配置文件
- 代码健壮性、容错性的处理
- 定制错误提示码方便定位错误
- 样式模块化和js模块化
- 组件化
最后放上项目目录结构的代码片段,大家可以研究一下,有问题一起探讨:https://developers.weixin.qq.com/s/1uVHRDmT7j6l
数据处理 与 数据获取 分开可以,不然看着 多层嵌套的语句确实难受😣
暂时只看了前面两条,给一些简易
分好项目目录结构
这个一定要预留好云开发的目录,即把小程序页面放在单独的目录里
做好接口配置文件
接口文件应该返回一个请求示例,而不是路径
接口一定要封装拦截器
返回请求示例,你是说封装请求吧
是的
很棒!加油鸭
棒!加油鸭
总结的挺好的。
项目结构可以根据项目大小适当修改下。对于分包的情况这样的结构会导致页面层级太深。调用起来不是很方便
受教了,学习学习!
我以为大家都是这么弄呢,原来我也会点架构啊。
受教了,准备抽时间按这种方式去优化一下代码
写的不做,架构师级别。很受用。
不不不,我只是底层搬砖的
我看到了架构师的思想在里面。我的目标是架构师,加油鸭
加油~
如果你前端用过vue和react框架的话,发现这些只是正常操作而已
为啥没有封装model框
model用的比较少,而且我们一般不用微信的model,都是自定义弹窗
搜嘎 希望多出点干货