因爲微信小程序 技術生態比較閉合,致使不少 現代前端框架不少積累出的成果都沒有實現(可能將來會逐一實現). 用慣了現代 再耍小程序 總感受很不順手. 前端
須要結果的請直接看最後的WXSes6
filter 理解爲管道加工處理, 你扔給我一組數據 通過各類不一樣類型的管道加工 產出新的數據 可是又不會影響修改原數據, 最終展現給用戶.web
現有前端框架filter通常:canvas
time | dateTime('yyy-mm-dd')
使用 | 做爲管道符 傳遞參數進行序列化小程序
截止目前,小程序官方並無管道實現方式,如下列出了替代幾種方案,供你們選擇使用.微信小程序
在請求完成以後 對返回值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須要 共享 就比較坑.前端框架
data : { time : 1511748300571 } get time (){ return FormatUtil.getDate(this.data.time); }
經過get方法來實現對字段顯示過濾. 只能操做對象 對數組中的item 比較無力.微信
微信小程序的架構分爲 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。
做者:魯小夫
連接:https://www.zhihu.com/questio...架構
瞭解了wxs 設計初衷,咱們也就知道能作什麼事情了.
wxs 目前主要是加強 wxml 標籤的表達能力
ps : 由於運行在不一樣線程因此 js與wxs 不能相互引用的. 這就有可能在js中使用公共方法 在wxs中須要從新寫一份(爲了共享filter) 形成代碼冗餘.
經過wxs 實現共享filter:
WXS 實現日期格式化(es6語法不能使用)
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
<wxs module="dateFr" src="../../../../filter/dateFr.wxs"></wxs>
使用filter
<text >{{dateFr.getTime(item.createdAt,':')}}</text>
wxs 基本知足filter的場景:
共享filter場景 採用3業務filter不少場景 採用1,3簡單業務filter 數據非數組型場景 採用2小程序還有很長的路要走,仍需繼續努力.