MUI的側(cè)滑菜單動(dòng)畫做得很不錯(cuò),其中分為兩種,一種是以webview,另一種是DIV形式
webview模式
主頁(yè)面和菜單內(nèi)容在不同的webview中,兩個(gè)頁(yè)面根據(jù)內(nèi)容需求分別組織DOM結(jié)構(gòu),mui對(duì)其DOM結(jié)構(gòu)無(wú)特殊要求,故其有如下優(yōu)點(diǎn):
菜單內(nèi)容是單獨(dú)的webview,故可被多個(gè)頁(yè)面復(fù)用;菜單內(nèi)容在單獨(dú)的webview中,菜單區(qū)域的滾動(dòng)不影響主界面,故可使用原生滾動(dòng),滾動(dòng)更為流暢;
另一方面,webview模式也有其缺點(diǎn):
不支持拖動(dòng)手勢(shì)(跟手拖動(dòng));主頁(yè)面、菜單不同webview實(shí)現(xiàn),因此若需交互(如:點(diǎn)擊菜單觸發(fā)主頁(yè)面內(nèi)容變化),需使用自定義事件實(shí)現(xiàn)跨webview通訊;div模式
主頁(yè)面和菜單內(nèi)容在同一個(gè)webview下,嵌套在特定結(jié)構(gòu)的div中,通過(guò)div的移動(dòng)動(dòng)畫模擬菜單移動(dòng);故該模式有如下優(yōu)點(diǎn):
支持拖動(dòng)手勢(shì)(跟手拖動(dòng));主頁(yè)面、菜單在一個(gè)頁(yè)面中,可通過(guò)JS輕松實(shí)現(xiàn)兩者交互(如:點(diǎn)擊菜單觸發(fā)主頁(yè)面內(nèi)容變化),沒(méi)有跨webview通訊的煩惱;
另一方面,div模式也有其缺點(diǎn):
不支持菜單內(nèi)容在多頁(yè)面的復(fù)用,需每個(gè)頁(yè)面都生成對(duì)應(yīng)的菜單節(jié)點(diǎn);主界面和菜單內(nèi)容的滾動(dòng)互不影響,因此會(huì)使用div區(qū)域滾動(dòng),在低端Android手機(jī)且滾動(dòng)內(nèi)容較多時(shí),可能會(huì)稍顯卡頓;
個(gè)人傾向于使用DIV模式,因?yàn)椴藛胃?yè)面之間的交互是很頻繁的,而且對(duì)于移動(dòng)APP來(lái)說(shuō)。支持拖動(dòng)手勢(shì)才是至關(guān)重要的。
下面簡(jiǎn)單的官方案例:
??...這里是菜單的內(nèi)容??主頁(yè)面標(biāo)題??這里是主界面具體內(nèi)容
mui.init({ ????swipeback:true//默認(rèn)左滑返回,可以達(dá)到offCanvas.hide的目的 ???? ??}); ?? ??mui('body').on('swiperight','.mui-content',function(){//綁定右滑事件,當(dāng)mui-content上發(fā)生右滑時(shí)(菜單原本是隱藏狀//態(tài)的) ?mui('.mui-off-canvas-wrap').offCanvas('show');??//顯示側(cè)欄 ??}); ??//關(guān)于側(cè)滑欄的動(dòng)畫有N種,這里是主界面不懂,菜單欄動(dòng)的效果,其他效果請(qǐng)到官方查看
關(guān)閉菜單還有一種方式,就是點(diǎn)擊菜單外面,所以為了增加這個(gè)事件需要以下代碼
mui('body').on('tap','.mui-content',function(){ ? if(mui('.mui-off-canvas-wrap').offCanvas().isShown()) ? { ? mui('.mui-off-canvas-wrap').offCanvas().close();? ? } ? ?})
因?yàn)榻壎ǖ氖莔ui-content,官方介紹中建議把頭部和底部導(dǎo)航之類的部分放在content外面,其他內(nèi)容放在里面,所以以上的綁定mui-content 觸摸事件可能會(huì)導(dǎo)致在菜單隱藏時(shí)候,都會(huì)執(zhí)行菜單隱藏代碼,為此需要加一個(gè)判斷,判斷菜單是否為顯示狀態(tài),isShown(),否則在菜單隱藏時(shí)點(diǎn)擊里面的內(nèi)容會(huì)報(bào)錯(cuò),Uncaught TypeError: Cannot read property 'offsetWidth' of null