前两天面试完百度，不知道能不能过，不过决定这几天暂停一下，闭个关学我的python。
有意思的是，面试期间，面试官问我能不能换技术栈，转vuejs。说部门项目都是vue或jssdk，不可能用react(“不可能”三个字咬得很重呢)。离开的时候我才想起，去年因为react那条有争议的专利条款，百度要求全面停止使用react/RN，但凡使用了react/RN的项目都迁移到其他框架去了。
其实作为前端开发者，我觉得用react还是vue技术栈都没关系，毕竟企业里技术还是为业务服用的。何况之前自己也玩过vue，上手也不难。
然后前天一个ios的同学跟我说，他现在已经什么都干了，最近还帮公司写了小程序，“上手很快，就是低端版的前端开发”。
我一听，也是时候玩一下小程序了，跟着文档过一下吧。
然后发现。。。这套东西TM就是山寨vuejs啊。。。。。
关于小程序生命周期、组件、api、发布上线之类的直接文档上就能查到，我也懒得做搬运工，只把目前觉得比较重要常用的东西做个小记。
----废话结束
小程序的架构分两层，即逻辑层(app-service)和视图层(page-frame),运行在不同线程，逻辑层的东西暂时没什么好讲的，文档中已经提供了各种api和微信能力调用，就前端而言，我们先关注视图层的构建和交互规则。
wxs：
小程序脚本，配合wxml构建页面结构。文档说是区别于js的一套脚本，但是在使用上和js非常相似。
要使用wxs，需要在wxml中定义一个wxs标签，
<wxs module="m1">
var str = 'abc';
var getMax=funcion(){}
module.exports.message=str;
module.exports.getMax=getMax;
</wxs>或者直接建立一个.wxs文件，然后在wxml中引用它：
<wxs src="./../tools.wxs" module="tools" />注意：每个wxs标签或文件就是一个模块，在wxml中定义或引用外部wxs时，要记得给wxs标签加上module属性，用于命名。
然后就可以在wxml中使用wxs中向外暴露的方法或数据。
<view> {{m1.message}} </view>
<view> {{m1.getMax(arr)}} </view> //arr 是页面js文件中data定义的数据wxs不能调用其他js文件中的函数，也不能调用小程序提供的api。wxs的函数也不能作为组件的回调函数。但是它可以对页面js传给wxml的数据进行处理，本质上就是运行在page-frame线程上的脚本，是为了降低逻辑层和视图层交互的开销。
自定义组件：
小程序里的自定义组件比较麻烦。一个基本的自定义组件，要创建一个文件夹，里面包含.json, .wxml, .wxss, .js文件，还要在引用组件的页面的.json文件中加上
{
"usingComponents": {
"component-tag-name": "path/to/the/custom/component" //标签名：自定义组件页面路径
}
}文档上有的我就不多说了。注意的是，自定义组件页面路径该怎么写：
我一开始好奇路径最右边该写什么后缀，后来查了下发现不用后缀就好了。
其实自定义组件中除了事件，还有三个很重要但不是必须的东西：behaviors、relations和抽象节点。
--behaviors：其实是用Behavior()构造器构造一个对象，这个对象有数据、属性、方法、生命周期。
假设我们在一个my-behavior的js文件里构造了一个Behavior实例，并module.exports出去。在自定义组件的js文件里：
// my-component.js
var myBehavior = require('my-behavior')
Component({
behaviors: [myBehavior],
...通过behaviors属性添加该实例。这个behavior的属性、数据、方法、生命周期就会合并到我们的自定义组件上，同名的情况下自定义组件的属性、方法优先级更高(具体就看文档啦)。因此behavior相当于是一个组件的增强器。
behavior的好处在于，自定义组件可以保持其自身独立性与通用性。而在某些场合下，如果我们希望给既有的组件添加某些行为或能力，可以通过给它搭配behavior定制化地增强其功能。
--relations：当我们的wxml大量使用自定义组件时，可能会遇到不同组件间（比如父子组件或同类组件）通信不方便的情况，小程序在组件构造器中提供了relations属性，让开发者可以告诉当前组件，其他某个或某类组件是他的父/子元素或祖先/后代元素，并绑定一些函数监听其他组件在节点树中的挂载、变动、卸载事件，作为通信机会。
我个人目前觉得，嗯。。。应该很少机会用到。。。
--抽象节点：其实就是所谓的泛型的概念。我们可以在自定义组件A中安插某个组件B，但这个组件B是未知的，当A被使用时，才显式定义B是哪个组件，借此提高页面构建的灵活性。
事件：
小程序中定义“自定义事件”非常简单。所以事件分原生事件和自定义事件。
// .wxml
<!-- 当自定义组件触发“myevent”事件时，调用“onMyEvent”方法 -->
<component-tag-name bindmyevent="onMyEvent" />
<!-- 或者可以写成 -->
<component-tag-name bind:myevent="onMyEvent" />
// .js
Page({
onMyEvent: function(e){
e.detail // 自定义组件触发事件时提供的detail对象
}
})触发自定义事件，需要在js中使用.triggerEvent('自定义事件名', myEventDetail, myEventOption)，如：
// .wxml
<button bindtap="onTap">点击这个按钮将触发“myevent”事件</button>
// .js
Component({
properties: {}
methods: {
onTap: function(){
var myEventDetail = {} // detail对象，提供给事件监听函数
var myEventOption = {} // 触发事件的选项
this.triggerEvent('myevent', myEventDetail, myEventOption)
}
}
})其中第二个参数是开发者自定义用来传递事件相关信息/数据的，第三个参数设置是否冒泡等。
我自己试了下，小程序里有三种触发事件的情况：
1.page层面定义回调，并在给自定义组件添加事件监听。此时和 给基础标签添加事件监听 一样。
2.在自定义组件的js文件里定义回调，并在自定义组件wxml内部添加事件监听。此时是组件对自己内部的标签添加事件监听，跟外层的page无关。
3.在自定义组件的内部定义回调，并在这个回调中使用.triggerEvent触发page层的回调函数。比如自定义组件内部有个button，绑定了tap事件，这个tap事件的回调里执行triggerEvent调用page层定义的某个函数。
template：
就是一段wxml模板，定义在wxml中：
<template name="msgItem">
<view>
<text> {{index}}: {{msg}} </text>
<text> Time: {{time}} </text>
</view>
</template>注意模板需要name属性，即给该模板命名。然后在wxml其他地方引用：
<template is="msgItem" data="{{...item}}"/>is属性用来指定使用哪个模板，data传入数据，记住data的数据命名要和模板里一致。
当同一个模板需要在多个页面中引用时，可以单独定义在一个wxml文件里，通过import 引用：
<import src="item.wxml"/>
<template is="item" data="{{text: 'forbar'}}"/>“import 有作用域的概念，即只会 import 目标文件中定义的 template”
最后，在小程序中进行网络请求时，要求使用https或wss。但是测试的时候可以不进行这方面的校验。
