原因： 在 Page 的控制邏輯中，非常需要知道當(dāng)前的 Page 屬于哪個(gè)路徑，以便于代碼復(fù)用。
現(xiàn)在的辦法是，使用隱形的 this.__router__
但這總不是個(gè)辦法吧。
建議在 Page 的 this 作用域中把 __router__ 顯性暴露出來
網(wǎng)友回復(fù)：
// pages/login/login.js
const route = pages/login/login.js
Page({
// you code here
onShow: () => {
console.log(route)
}
})
你自己的代碼是可以知道當(dāng)前是哪個(gè)route的呀
我們現(xiàn)在就是用您的這個(gè)方法做的，但是 這樣很低效。
目前這樣做的原因是擔(dān)心 __router__ 這個(gè)隱形屬性不可依賴。
因?yàn)橛?0多個(gè)form page，我們需要實(shí)現(xiàn)的是保存(save) 并恢復(fù)(restore) 用戶在 form page 上的輸入。
那么 page router 是一個(gè)非常合適的 storage key。
再往深里看
這些 form pages 的 save / restore / input validation 都是大量重復(fù)的邏輯。因此一個(gè)更合理的模型是使用助手方法抽取掉大量重復(fù)的邏輯。 而 Page 的 onHide / onShow / onLoad / onUnload 正好完美的把助手方法生產(chǎn)的方法實(shí)例綁定到當(dāng)前的 page 作用域上。
因此 我覺得 讓 Page 能夠在自己的作用域下自我識(shí)別是有很大好處的。
__router__ 這個(gè)私有變量在可預(yù)見的未來都是不會(huì)刪除的，可以正常使用
不過使用沒有暴露在文檔中的變量確實(shí)不好，我們會(huì)考慮直接直接暴露出 router 變量，并且在文檔中標(biāo)明
非常感謝！
更新的1.2.0版本已經(jīng)可以使用 page 的 route 字段獲取當(dāng)前頁(yè)面的路徑了
很贊
