在小程序中,我們經(jīng)常有調(diào)起鍵盤的操作場景,但是在不同的場景下解決方案不盡相同,還是需要具體問題具體分析。 需求分析最近在項目中有一個需求,是從列表頁點擊評論按鈕進入詳情頁時,在加載完頁面后自動調(diào)起鍵盤進入評論狀態(tài)。從需求來看,我們應該在onReady函數(shù)中調(diào)起鍵盤,因為onReady函數(shù)是在頁面初次渲染完成時被調(diào)用。但是在實踐中我們發(fā)現(xiàn),對于一些配置不好的手機,其加載頁面速度較慢,在onReady函數(shù)調(diào)用時頁面并沒有渲染完畢,就會導致placeholder和input組件位置錯亂的現(xiàn)象。其本質(zhì)原因是,onReady生命周期函數(shù)并不能在調(diào)用時承若已經(jīng)將頁面渲染完成了。(盡管文檔中描述是已經(jīng)完成了。) 之前的操作是在onReady生命周期函數(shù)中調(diào)起鍵盤。
this.setData({ focus: true })
復制代碼
發(fā)現(xiàn)這個問題后做了相應的延遲處理
setTimeout(() => {
this.setData({ focus: true })
}, 300)
復制代碼
但這是治標不治本的方法,手機性能好的用戶會無謂的等待300毫秒,而手機性能很差的用戶等待300毫秒也不一定就能解決這個問題。 解決思路那么既然小程序并沒有提供給我們一個理想的渲染結束后的回調(diào)函數(shù),那么我們就換個思路: 使用短輪詢來處理,當頁面渲染完成后才調(diào)起鍵盤的操作。
既然要使用短輪詢,那么我們?nèi)ポ喸兪裁茨??什么標志代表著頁面渲染完成了呢?在這里,我是使用
let timer = setInterval(() => {
wx.createSelectorQuery().select('#comment-section').boundingClientRect(rect => {
if (rect !== null && timer !== null) {
clearInterval(timer)
timer = null
this.setData({ focus: true })
}
}).exec()
}, 50)
復制代碼
在此之上,如果我們只粗暴的讓
在調(diào)起鍵盤時默認頁面會上推,如果在評論很少的情況下這樣的體驗并不好。所以需要判斷一個高度,超過這個值就上推,沒超過就不上推。這個值視實際情況而定。 上推的操作是由input組件的
// 在this.setData({ focus: true })前對節(jié)點高度進行判斷
if (rect.height < 500) this.setData({ push: false })
else this.setData({ push: true })
復制代碼
onBlur函數(shù)問題
在實際的操作中,我們發(fā)現(xiàn)在鍵盤被調(diào)起后會有概又自動收回。經(jīng)過排查發(fā)現(xiàn)時onBlur函數(shù)的問題,在onBlur函數(shù)中,我們手動的設置 封裝起來雖然我們完成了這次任務的需求,但是顯而易見的,這樣的任務在未來肯定還會再次出現(xiàn)。所以機智的我們應該趕快把整套流程封裝起來,以便下次直接調(diào)用。 那么這時我們使用的方式就是這樣的:
const Util = require("xxx") // 引入封裝的庫
/**
* 生命周期函數(shù)--監(jiān)聽頁面初次渲染完成
*/
onReady: function () {
Util.onTotalReady('#comment-section', 50, rect => {
if (rect.bottom < 500) this.setData({ push: false })
else this.setData({ push: true }}
this.setData({ focus: true })
})
}
復制代碼
小結在解決鍵盤調(diào)起的這個過程中我們可以看出微信小程序開發(fā)流程的簡陋,這個問題的出現(xiàn)本質(zhì)上是小程序提供給我們的生命周期函數(shù)的不夠準確。否則在頁面渲染完成的情況下我怎么會拿不到節(jié)點信息呢?像react中的componentWillMount生命周期函數(shù)中就不會出現(xiàn)這樣的問題,所以希望小程序能再變強大一些,也讓我們少寫一點這種hack代碼。 |