今天花了半天的时间阅读微信小程序API,然后实现了一个又难看又没有什么用的微信小程序。
微信小程序
微信小程序是什么?
官方的介绍:
微信小程序是一种全新的连接用户与服务的方式,它可以在微信内被便捷地获取和传播,同时具有出色的使用体验。
个人的看法:
我个人的看法是微信小程序并没有什么前景。小程序与原生APP或者webApp相比,它的优势并没有早先宣传的那么明显,我个人也不认为它可以取代原生应用,即使是在一些它本身占优势的方面。
让我们来看一下官方的介绍,突出的三点是:
- 小程序是全新的连接用户与服务的方式。
- 小程序可以在微信内便捷地使用和传播。
- 小程序具有出色的用户体验。
首先,小程序是全新的连接用户与服务的方式,新旧与否这也并非用户会关注的点,反而用户可能不会去放弃现在使用中的APP去替换成一种新的交互方式。
其次,小程序可以在微信内便捷地被使用和传播。我们不可否认微信的成功和在国内庞大的用户量。但是这足以促成小程序的成功吗?并不会,事实上,应该有相当大的一部分微信用户根本没有听说过小程序吧。而给智能手机下载APP,我相信拥有智能手机的人大部分都有经历过。我想,这是一种根深蒂固的观念,妄图改变,并不在自己的用户量的优势上面,而是需要有翻天覆地的技术革命。
是的,小程序可以通过简单的分享功能来传播,但是小程序的诸多限制,却又不利于扩充小程序包含内容的丰富程度。简单来说,功能多,就失去了加载快等特性,而且小程序本身框架的设计也并非容器是实现多样化的功能(暂时个人的看法)。而功能少,却不足以拥有留住用户的基础。并且,添加到桌面这个功能,可能相当大一部分用户并不会使用到,那么从小程序的入口进入,又相对比较麻烦。
最后,小程序具有出色的用户体验。确实,小程序的设计理念决定了它做出来后界面简洁,功能专一,加载迅速。相对来说,广告较少,比较纯净。但是大多时候我们需要提供给用户的却往往不止这些简单的小功能,而小程序封闭的框架又限制了某些功能的提供(个人现在的看法)。所以,最终还是要靠原生APP或者webApp去实现。小程序也只是能够起到一个锦上添花的作用而已。
现在的小程序,只是一个玩具而已。
用户体验
谈谈用户体验。
看过一句话,说网络的三大生产力是--性,免费和无聊。
我现在要提出一个观点,用户体验应该针对的点是:美,懒,快和无脑。
美和快不必多说。别的这里解释一下。
懒,用户特别懒。
我们可能会经常看各种新闻,网站,论坛之类的,我想大多时候我们只是在看,很少去点赞或者评论。
究其原因就是,我们懒。我们没有要去做那些操作的理由或者想法。而一些诱导分享的内容却往往得以迅速的传播,再究其原因,那就是能够给用户带来的利益。
人本身就是无利不早起的。那么我们如果想让小程序更好的发展,首先它要能提供一些相比原生APP更加优质的服务。比如--无广告(国内好多公司应该好好去做)。
想起一个说法就是你装个APP,提供商恨不得把他爹都给塞进去。问题是那些功能,我们是否真的可以用到,当然不是。而且有的甚至还会误操作多,体验真的很不好。
那么,现在有一个纯净版的小程序,我们可以添加至手机桌面,点开就用,那么无疑是可以吸引到用户的。
再说无脑,用户可能不知道可以添加小程序到桌面,
那么,从手机桌面进入原生APP需要点击一次,而从小程序进入,要先打开微信,再切换到发现栏,再点击小程序,再点击要打开的小程序。这用户体验,根本不需要比较。
当然小程序提供了添加桌面的功能,前提是用户发现它,使用小程序的人并不多,那么用户在第一次使用小程序的时候,怎么发现这个功能呢。嗯,需要开发去做提醒。
永远记住,避免让用户思考和发现。
让用户去选择,比让用户去输入要好。规范用户的输入,比用户犯错之后提示会更好。
开发体验
关于如何开发微信小程序,官方文档介绍的很详细,这里我就不Copy那些API了,并没有什么意义。
这里我来谈一下,我个人在尝试开发小程序时候的感受。
因为整个开发和学习的时间就是今天的下午,大概几个小时而已,实现的功能也非常简单,只是做了几个简单的数据查询展现的页面,所以可能有些在我认为有点坑的地方只是我对API不够熟悉而已。
但我想,这也可能是别的初学小程序开发者可能会遇到的问题。
首先,注册小程序,需要绑定一个没有绑定过邮箱,我有点搞不清楚这里没有绑定过的定义,不过应该是指没有绑定过微信号吧。
我有5个邮箱,三个试过后已经绑定过了,gmail则是根本无法绑定。我觉得这比较麻烦,大多人的常用邮箱应该在2个左右。但是可能会去绑定的小程序就不止一个。
其次,微信小程序开发者工具。这个工具,我真的感受不到什么优越性,确实提供了一些开发中的便利,比如对数据的监控,实时保存编译,自动生成页面文件等等。但它也将小程序的开发环境限制了。
我个人倾向于小程序能够做一个像Vue-DevTools那样的chrome插件,加上小程序专有的cli再加上各种插件。这样也能让我在自己常用的编辑器加上自己的习惯配置下工作。
毕竟,习惯是很可怕的一件事情。
再说说小程序提供的常用组件。
- 布局组件
view
- 文本组件
text
- 链接组件
navigator
- 图片轮播组件
swiper
- 图片组件
image
- …
我只能说太有限了。当然这也是它设计理念的一部分。但是总感觉比如文本全是一个text组件,再去各种写样式去控制文本的展现,真的有点不方便的。
再说说小程序的目录结构
小程序项目的根目录下面包含3个文件,app.js, app.json, app.wxss
。分别功能是js生成应用App实例,json进行全配置包括页面,主窗口,底部导航和网络超时设置,wxss进行全局样式设置。
而在每个pages下面的页面中,我们又要定义4个同名的不同格式文件foo.wxml, foo.js, foo.wxss, foo.json
。分别是页面布局,样式,行为,数据和配置。
因为微信小程序的应用都是在移动端,而且是内建于程序内的,所以可以放心使用各种CSS3属性,flex布局和ES6语法、
而有关小程序提供的API方面。小程序的页面js提供有各个阶段的生命周期函数,自动监听页面的加载阶段,以方便执行不同的行为。小程序还提供了一套wx.apiName()的API来实现微信上常见的小功能。例如wx.showToast(),wx.request(),wx.navitateTo()。这些内置API都可以简单的进行配置,来实现多样化的效果。
小程序使用了模板语法,和组件上的自定义指令。这一点和例如vue之类的现代MVVM框架十分类似。语法上有很大的相同点。相信像我一样学习vue的同学学习起小程序开发应该可以快速上手。
但是小程序不能引入外部的样式和脚本文件又决定了这是一个比较封闭的生态。
总之,小程序有其优点,但是我个人并不看好。开发难度,我目前做点小功能,还尚可。不过我相信如果需要较高程度的自动化就会有不小的坑。
踩坑记录
踩坑是一种乐趣。
项目目录选择
微信小程序开发工具初始化一个项目需要从一个已经存在的文件夹开始。而不是在初始化的时候去创建一个文件夹。
所以如果你想做个小程序项目,那么就从先给你的小程序起个名字,建立一个文件夹开始。
页面跳转失效
今天在开发的时候做页面跳转,我先再元素上绑定了bindTap属性,然后在js里写了对应的方法,然后问题来了,点击事件触发后,页面根本无法跳转。
经过搜索后才发现,原来在
app.json
里的tabBar分页导航设置的页面是无法通过wx.navigateTo
跳转的。解决方法将页面从tabBar中去掉,或者提醒用户点击tabBar替换页面,建议前者。
获取用户表单输入
方式一、 讲表单至于form组件中,再在form的bindSubmit事件中使用e.detail.value获取表单的所有值组成的对象。格式·name: value·。
方式二、 让input的输入与js的Data属性中的某个字段双向绑定,触发事件的时候重新读取这个数据。
页面间传值的方式
通过url的search段参数来实现类似动态的路由效果,那么我们就需要页面间的传值。
传值很简单,通过
name=value
的格式来组成,再将其拼接在url的search段后。那么如何去接收这个值呢?
我们可以在onLoad生命周期函数中传入一个对象,再通过这对象下面的key来获取对应的value。
1 | Page ({ |
格式化字符串再模板输出
这是我今天在做的小项目里的一个需求,服务器返回的时间格式需要修改。
在vue中我们有fiter的功能,甚至可以自定义fiter。
然而在微信小程序中,我尝试了在模板语法支持的表达式中来格式化时间。失败了。
在js的生命周期里,用map方法修改数据的时间属性,仍然失败。
目前还没想到优雅的解决方案。
其余小坑
- 在wx.apiName()中记住这里调用的是wx实例的方法,而当我们要进行一些操作时候,需要再全局韩静下使用。所以我们可以在这些函数前声明
let that = this
。再通过that来操作。 - 要使用data字段的数据 需要这样来操作
this.data.dataName
。 - 要修改某个数据的值,使用this.setData()比较好。
- 在wx.apiName()中记住这里调用的是wx实例的方法,而当我们要进行一些操作时候,需要再全局韩静下使用。所以我们可以在这些函数前声明