摘要:filter 理解为管道加工处理, 你扔给我一组数据 经过各种不同类型的管道加工 产出新的数据 但是

filter 理解为管道加工处理, 你扔给我一组数据经过各种不同类型的管道加工产出新的数据 但是又不会影响修改原数据, 最终展示给用户。由于微信小程序技术生态比较闭合，导致很多 现代前端框架很多积累出的成果都没有实现，用惯了现代再耍小程序 总感觉很不顺手。
截止目前,小程序官方并没有管道实现方式,以下列出了替代几种方案，供大家选择使用。

直接修改原数据

在请求完成之后 对返回值data进行一次数据处理 比如 抽象一个_formatListData方法对 返回进行二次处理.
_formatListData(list) {
return list.map((item) => {
let date = FormatUtil.getDateTime(item.childBirth);
item.filterChildBirth = `${date.y}-${date.M}-${date.d}`;
return item;
}
}

这种方式会给原数据添加新字段 filterChildBirth (原字段为 childBirth) . 最终展示也是显示filterChildBirth 到view上面，多个需要filter的字段都通过这种方式去处理,很明显 对一些业务型filter倒还好，如果遇到filter需要共享就比较坑。

ES6 get

data : {
time : 1511748300571
}

get time (){
return FormatUtil.getDate(this.data.time);
}

通过get方法来实现对字段显示过滤. 只能操作对象 对数组中的item 比较无力。

WXS

微信小程序的架构分为 app-service 和 page-frame，分别运行于不同的线程。你在开发时写的所有 * 都是运行在 app-service 线程里的，而每个页面各自的 WXML/WXSS 则运行在 page-frame 中。app-service 与 page-frame 之间通过桥协议通信（包括 setData 调用、canvas指令和各种DOM事件），涉及消息序列化、跨线程通信与evaluateJavascript()。这个架构的好处是：分开了业务主线程和显示界面，即便业务主线程非常繁忙，也不会阻塞用户在 page-frame 上的交互。一个小程序可以有多个 page-frame （webview），页面间切换动画比SPA更流畅。坏处是：在 page-frame 上无法调用业务 *。跨线程通信的成本很高，不适合需要频繁通信的场景。业务 * 无法直接控制 DOM。

wxs 目前主要是增强 wxml 标签的表达能力。因为运行在不同线程所以 js与wxs 不能相互引用的. 这就有可能在js中使用公共方法 在wxs中需要重新写一份(为了共享filter) 造成代码冗余。

WXS 实现日期格式化

var DateFr = {

getDate: function (time, splitStr) {

if (!time) return '';

var date =getDate(time);

var M = date.getMonth() + 1;

var y = date.getFullYear();

var d = date.getDate();

if (M < 10) M = 0 + M;

if (d < 10) d = 0 + d;

if (splitStr)

return y +splitStr + M +splitStr+d;

else

return {
y: y,
M: M,
d: d
};
}
}
module.exports = {
getDate: DateFr.getDate
}

在业务页面wxml中引用wxs

使用filter
{{dateFr.getTime(item.createdAt,':')}}

wxs 基本满足filter的场景

推荐阅读：微信小程序开发库有哪些 微信小程序开发教程