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