微信小程式:getCurrentPages()的使用
有不少朋友剛接觸小程式的時候,也許會有這麼一種感覺:“我草,用資料去重新整理頁面,屌屌的”,也有朋友像我一樣發出這樣的感覺:“我草,這是向android看齊了嗎?”,當然,還有人有這個感覺:“抄襲vue的,不用懷疑了”,
既然大家都有感覺vue是抄襲小程式的,那麼我們今天就來說說小程式的資料驅動吧
對於vue,大家想起來的估計有三個英文字母。spa,啥是spa?spa的意思就是單頁面應用,既然如此。那麼小程式會不會也是一個spa?
當然,這個文件有沒有說,就要大家自己去查找了,
spa的最大好處(個人絕得),就是資料的通用性,比如在util。js中放置了一個數據,然後在其他的js中也是可以讀取的,那麼這樣下去,我們就彷彿有了一個另類的資料庫,但是這個資料庫存在的時候是否有點過長了?這個就不是我們擔心的了
既然如此,那麼微信小程式裡面是否也有這個“資料庫”?
當然是有的,就是“app.js”,畢竟人家是很久遠,一直永流傳的,所以說,我們比較多的操作實在app.js內部操作的,
當然,很多人還是喜歡在util裡面寫配置,可能我是個怪胎,
既然我們在app。js裡面寫下了通用程式碼,以及一些公用的方法,對於資料共用的重要性,相比大家都明白,試想下這麼一種場景,當我們在app。js中獲取到了使用者的資訊之後,我們只需要儲存起來,然後我們再接著在其他的頁面中獲取使用者資訊的時候,我們不需要去重新獲取,只是需要去讀取我們的app。js就可以了,很是方便,
相對於“操控”與“反操控”,或者說是:“獲取app。js的數值”與“讓app。js去主動重新整理我們的介面”。這兩點視乎是並不對立的,而且我們也可以很輕易的實現第一點,但是第二點確實有點麻煩。
我也曾想過讓app.js與某一個js調換下位置,但是失敗了,
想想下下面這個場景:
作為一個線上應用,我們最需要的是與後臺資料的事實重新整理,比如,使用者獲取列表的操作,我們需要及時傳送到後臺嗎,並且根據返回的資料重新去排版頁面。在舉個麻煩點的例子
我們都知道,一個即時通訊的程式,最喜歡的就是socket,但是小程式這邊的話最麻煩的是當一個頁面被銷燬的時候,那麼他的socekt也會看弄死,這個時候,我們需要考慮下生命程序的問題,那麼我們最好的打算的話,是將socket的監聽放在app,js的地方,那麼我們就只是需要 考慮下心跳時間以及如何在app.js中更新頁面的資料。第一個問題是不需要我們過分操心的,我們只需要在使用者cd的時候做一系列操作就可以去避免這個的發生,但是第二個的話就是我們的難點了。也好在小程式提供了getCurrentPages來使我們度過這個難關,getCurrentPages返回的是當前棧的路徑,以及該頁面的資料,那麼我們就可以實現類似下面的demo了
app.js
//app.js
App({
onLaunch: function () {
const that = this;
setTimeout(function () {
getCurrentPages()[0].showmessage();
}, 5000);
},
globalData: {
userInfo: null
}
})
a.js// pages/a/a.js
Page({
/**
* 頁面的初始資料
*/
data: {
msgdata: "尚未重新整理"
},
showmessage: function () {
this.setData({ msgdata: "這個是ap.js去重新整理的" });
}
})
a.wxml{{msgdata}}
也許,這個可以說明小程式也是一個spa應用?