写微信小程序所感

---

.0000 续s

那是一个夜黑风高的清晨，逛 GayHub的时候，猛然之间发现了一个相当因吹斯听的项目itChat，思量着也许可以实现一些好玩的事情。

然而也许是那天摸爆了，根本不想写代码，于是点了个 stars 就歇了。

没想到晚上的时候又发现了wxpy这个项目，简直就是上天给我的 warning 啊，这特么还不开搞？

我的想法是做一个使用微信就能简单查看自己在 GitHub Stats 过的项目列表和详情。

之后限于微信的API 太封闭(技术不够)，玩着玩着就没兴趣了，留下一个烂尾项目。想着等什么时候小程序开放个人注册了再说。

本来以为要到猴年马月的，毕竟马哥都说小程序是为线下第三方服务的了，结果居然没过几天就开放注册了，我当时的表情就是（？？？）

于是我就兴高采烈的去好好的沾了沾小程序的余温。

却没想到还是看到了火的时代的终结，以及深海时代的来临。

---

.0001 初体验

身为一个资(mo)深(yu)后台程序猿，看到小程序的所有逻辑都是由 js 控制的时候，我几乎是崩溃的。

仿佛又想起了那些年被 js 支配的恐惧。语法混乱，难以理解，无规无序，xjb 写。

但是既然要写，就趁机再好好学学 js 吧，毕竟现在那么多火炸的开源项目都是 js 写的。

于是我点开 js 教程，点开小程序官方手册，准备开搞。

ps: 略过下载开发者工具，注册小程序，配置 appID 之类繁琐的步骤。

---

.0010 配置

参照

无论做什么，首先第一步就是配置嘛（？

小程序的（全局）配置文件为 app.json，这个文件配置的是这个程序的一些全局显示模式和页面，像默认标题栏，tabBar，需要加载的页面之类的。

所以首先要想象出我所要实现的程序的显示效果和基本的逻辑。

嗯，还是非常形象的。

于是开始初始化项目。

大概就是这样了。

因为无(you)聊(bing)，所以加了个热门(trending)页面，估计要坑了（。

搭好文件之后，把每个页面的路径写入 app.json 中，这样最初的框架就搭好了。

---

.0011 开始搞事情

参照

接下来开始看 app.js 文件。这个文件处理一些全局的逻辑，比如小程序刚刚启动的时候需要加载的东西，以及全局变量的配置。

需要注意的是在别的页面访问全局变量的方式是 var app = getApp(); 这样获取app.js的实例，然后用app.globalData.yourData 访问全局变量。

有些时候会把一些公有函数写在这个文件里，不过如果有公有函数，我更倾向把它们单独封装在一个文件里在暴露接口。

可能我有入口页面简洁强迫症吧。

这个文件没有什么好写的东西，到之后处理逻辑遇到再编辑也行。

---

.0100 WXML & WXSS

参照

1、最让人不爽的东西大概就是 wxml 和 wxss 吧

拿了一半 html css 的东西，可是又不拿完，留下一些不兼容的特性，简直让人费解。到后面的 js 更是如此，简直感觉自己在写盗版 js。也许这就是企鹅厂的作风吧。

让人欣慰的是，wxml 的列表渲染封装的不错，只要在属性调用 wx:for="{{data}}" 就会自动遍历 data 中的数据，不过现在要加上 wx:key="key"来指定项目唯一标识符，不然会报一个 warning，我讨厌 warning。

官方文档对渲染的东西写的很明确，就不赘述了。只要用一个模板写好列表数据的格式，在当前文件引用模板，然后对他列表渲染，就 ok 了。

2、比较关键的是事件处理的问题

wxml 的组件基本都有事件响应的属性，可以在组件中绑定一个事件处理函数。

因为我们的要渲染列表数据，一般列表数据都会有上拉加载和下拉刷新的功能，小程序中有两种方式实现这两个功能。

1. 用小程序内置事件处理函数onPullDownRefresh，要在app.json的 window 选项中开启 enablePullDownRefresh
2. 用 scroll-view 组件中的bindscrolltoupper和bindscrolltolower属性

我选择了第二种。

使用 scroll-view 组件实现上拉下拉触发的时候要写upper-threshold和lower-threshold的参数，这两个属性表示上拉下拉的触发范围。

<scroll-view class="scroll-stars" style="height:{{windowHeight}}rpx" upper-threshold="0" lower-threshold="0" scroll-y="true" 
    ...
</scroll-view>

上拉和下拉的逻辑处理等下再细说。

3、然后是 wxss

其实并没有什么要说的，毕竟就是 css 嘛，直接拿一堆 css 样式贴进去就好了…

主要是对于 rpx 和 px 的区别。

官方是说 1rpx = 0.5px = 1像素，而且并没有推荐使用哪种单位。

不过根据我实机(iphone 6p, ios10.3, WeChat6.5.6)测试来看，px 的设定是绝对的，rpx 会根据屏幕的不同进行适应。

---

.0101 不存在的逻辑

参照

搞定显示层的一堆 p 事之后，我们可以开始处理逻辑了。这才是整个程序的核心，当然也是整个小程序最恶心的东西。

这句话除了最后一段都是假的。

小程序提供的 API 几乎全都是异步的，虽然异步真的非常好，也不能这样用吧？

在实际开发的时候遇到最令人心碎的问题几乎都是回调地狱了。

例如我调用 wx.getUserInfo()想获取用户名，结果它是个异步函数，可是我就是想要一个返回值而已啊，于是我还要写回调函数处理返回值，还要处理原函数让它等待结果返回了再继续执行。

可是我只是想要函数的返回值而已啊。

var that = this;

wx.login({
  success: function() {
    wx.getUserInfo({
      success: function(res) {
        wx.setStorage({
          key: that.data.keyName,
          data: res.userInfo.nickName
          success: function() {
            console.log("where am i");
          }
        });
      }
    });
  }
});

简直就是折磨。

后来当我四处寻找真正的 js 的时候我才猛然发现，在真正的世界里，用着正版 js 的人们是何等的幸福，有着各种好用方便又漂亮的 js 框架、工具，数不胜数，把一门曾经能让人恶心到的语言包装成了现在最耀眼的星星，这时我才知道为何现在 js如此的大放异彩。

这个世界上没有垃圾语言，只有不会用的程序员。

以及

这世上从来不缺天才程序员。

教练，我要学 js。

至于上拉加载

先把东西扔这儿。

上拉加载主要的问题在于，实机测试的时候，上拉加载总是会多次触发请求。原因不明。

刚开始我以为是 scroll-view 组件和 tabBar 一部分重叠的原因，但是减去 tabBar 的高度后还是有同样的问题。

然后我以为是 scroll-view 的触发距离太大了，但我把触发距离调成 0 也没有什么卵用（好像不那么频繁了？）。

我觉得这应该就是小程序的设定吧，用手滑窗口的时候会造成多次触发，既然这样就只能在程序里做限制了。

解决问题的主要逻辑就是设置一个全局变量用来判断当前是否还是处于加载状态，也就是判断回调函数有没有被调用。

中间试了很多不同的方式想要达到同样的目的，像是用setTimeout()来延迟程序的执行、用 ES6 api 的 promise 把异步代码同步表述。

很奇怪，最后都失败了。

最神秘的是我把现在这种解决方法的全局标志变量写进 data 中，也失败了。让我怀疑我是不是生活在异(er)次元。

至于下拉刷新，嗯，摸了。

---

.0110 果然没用完一个二进制位

经过这一次痛不欲生的踩坑之旅，我更加坚定了走后台的决心:)

当然，也出乎意料的了解到了 js(ECMAscript) 的美好，其实我本以为小程序应该会让我好好感受一下微信团队的技术。

结果我只看到了无谓的野心和半成品一样的产品。

我一直认为互联网一直发展到如今的蓬勃很大一部分离不开开放平台的标准，像 http、html、ECMAscript，社区贡献标准，标准再回馈社区。这才使得这些标准愈发强大、才使得互联网愈发蓬勃。

可是在小程序里我只看到一种病态的自闭，分明借用了 js 的语法标准，却把 js 中很多精华完全抛弃；想要自成生态闭环，却还欲拒还迎的使用 js。

神经病啊（震声

该回去学 py 了。

项目仓库

有兴趣的可以点个 stars 什么的，没兴趣的…没兴趣的也看不到这里吧。