令人舒適的Tab頁面交互效果？
tab頁面的交互效果，感覺挺有講究，有許多小細(xì)節(jié)在里面。
不過使用Tab先要確定方向，就是需不需要即時(shí)刷新的需求。
經(jīng)過多次對(duì)比和體驗(yàn)眾多的小程序。tab頁面在切換tab item的時(shí)候，需要即時(shí)刷新的頁面 多是：【訂單管理頁面】，它一般涵蓋【全部訂單、待付款、待發(fā)貨、待收貨、待評(píng)價(jià)】等?；蛘呤窃谏唐妨斜磉M(jìn)行條件篩選的時(shí)候【綜合、銷量（升降序）、價(jià)格（升降序） 等?！?/p>
這些在交互上，用戶也是希望可以獲得即時(shí)最新的數(shù)據(jù)的，所以刷新請(qǐng)求數(shù)據(jù)，用戶反而沒有那么“不喜歡”。
但是對(duì)于另一種，【閱讀類】，或者【發(fā)現(xiàn)類】的Tab項(xiàng)目，在切換tab的時(shí)候 頻繁刷新頁面，就是一種很奇怪的體驗(yàn)。
比如使用者在 Tab-1 里瀏覽列表，將頁面滾動(dòng)到了距離頂部 1500rpx的距離，用戶點(diǎn)擊Tab-2 頁，又繼續(xù)從高度為 0 的 Tab-2 view瀏覽列表。
然后在切換回Tab-1 頁面。如果此時(shí) Tab-1 又重新請(qǐng)求了數(shù)據(jù)，并且將原來停留的1500rpx距離又置為了0，這無疑是很糟糕的。
用戶希望 Tab-1的瀏覽位置繼續(xù)保留，而不是被重新刷新了，因?yàn)槭褂谜哌€想繼續(xù)接著 往下瀏覽。
而且還有 有tab頁的地方，個(gè)人覺得 tab的選項(xiàng)應(yīng)該 固定定位在 頂部，讓tab選項(xiàng)不會(huì)隨著頁面的滾動(dòng)而被翻上去。
拋出問題：
【痛點(diǎn)】按照正常的布局來說，H5的tab頁面 tab-item之間相互切換，滾動(dòng)高度是會(huì)被繼承的。
比如tab-1瀏覽了2000的高度，切到tab-2時(shí)，tab-2的高度也是2000，tab-2繼續(xù)瀏覽時(shí)，切回tab-1，tab-1又關(guān)聯(lián)了tab-2的滾動(dòng)高度。
【bilibili小程序tab】研究：：
直到我看到 bilibili小程序? 的tab體驗(yàn)，發(fā)現(xiàn)它的交互是非常貼近原生app的那種感覺。就是tab-item相互切換之間，高度不會(huì)相互影響。而且是支持手滑切換。已經(jīng)加載過的item，不會(huì)再次進(jìn)行數(shù)據(jù)加載。每個(gè)item的滾動(dòng)高度都是停留在使用者 閱讀的那個(gè)位置。
后來我通過查閱和實(shí)驗(yàn)。發(fā)現(xiàn)bilibili小程序的tab頁制作使用了一些“巧”的技術(shù)。
總體結(jié)構(gòu)是：
自定義選項(xiàng)卡的 選項(xiàng)按鈕（切換按鈕）? + swiper組件內(nèi)scroll-item再嵌套scroll-view組件實(shí)現(xiàn)（對(duì)應(yīng)的內(nèi)容視圖）。
用swiper來嵌套的目的是，是的選項(xiàng)卡支持手滑切換視圖，并且聯(lián)動(dòng)到 自定義的選項(xiàng)按鈕高亮。增加體驗(yàn)。
這里是選項(xiàng)卡頭部 綁定 swiper的 cur 值來監(jiān)聽對(duì)應(yīng)的索引
<view class="tab-wrapper">
? ? ? <view bindtap="tabfun" class="tab-list {{swipercur==index?'cur':''}}" data-index="{{index}}" wx:for="{{tab}}" wx:key="{{index}}">
? ? ? ? {{item.txt}}
? ? ? </view>
?</view>
這里是選項(xiàng)卡的內(nèi)容項(xiàng)目
<swiper>
? ? ? ? <block>
? ? ? ? ? ? <swiper-item class="swiper-item ">
? ? ? ? ? ? ? ? <scroll-view class="scroll-view-wrapper"
? ? ? ? ? ? ? ? ? scroll-y
? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? <!-- 視圖內(nèi)容 1 -->
? ? ? ? ? ? ? ? ? </scroll-view>
? ? ? ? ? ? </swiper-item>
? ? ? ? ? ? <swiper-item class="swiper-item ">
? ? ? ? ? ? ? ? <scroll-view class="scroll-view-wrapper"
? ? ? ? ? ? ? ? ? scroll-y
? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? <!-- 視圖內(nèi)容 2 -->
? ? ? ? ? ? ? ? ? </scroll-view>
? ? ? ? ? ? </swiper-item>
? ? ? ? </block>
? ? ? </swiper>
不過小程序的 view 視圖里使用了 scroll-view組件是有注意事項(xiàng)的官方說明如下：
tip: 在滾動(dòng)?scroll-view?時(shí)會(huì)阻止頁面回彈，所以在?scroll-view?中滾動(dòng)，是無法觸發(fā)?onPullDownRefresh
tip: 若要使用下拉刷新，請(qǐng)使用頁面的滾動(dòng)，而不是?scroll-view?，這樣也能通過點(diǎn)擊頂部狀態(tài)欄回到頁面頂部
也就是說，它無法監(jiān)聽 page 的下拉刷新事件。
好在scroll-view 組件有自己的一些屬性和方法支持 類似效果目的
bindscrolltoupper ：監(jiān)聽scroll-view是否到達(dá) 頂部/左部
bindscrolltolower ：監(jiān)聽scroll-view是否到達(dá) 底部/右部
text： 為使用者多考慮一環(huán)
在涉及一些 【手機(jī)號(hào)】，【地址】，【標(biāo)題】，【線索】等 字段的時(shí)候，我會(huì)用 view嵌套text包多一層。因?yàn)閠ext附帶了?selectable 屬性。可以支持 文本是否可選
加上這個(gè)屬性，使得重構(gòu)頁面不會(huì)冷冰冰。而是當(dāng)使用者 在有需要選擇文本的時(shí)候，剛好支持選擇，進(jìn)行拷貝或者其他操作。
“坑”：小程序input 、textarea 等組件z-index層級(jí) 非非非常高。
?選擇列表自定義組件使用 cover-view 和 cover-image 組件代替view和image，cover-view 和 cover-image 組件，可以覆蓋在部分原生組件上面。
?
“坑”：小程序 input 動(dòng)態(tài)改變type 的值
小程序 input 動(dòng)態(tài)改變type 的值，在開發(fā)者工具調(diào)試有效。而在真機(jī)居然會(huì)出現(xiàn) 不可理喻的BUG
場(chǎng)景需求是：密碼登錄框，支持眼睛開合切換。即是 眼睛打開的時(shí)候 ，顯示密碼 type=’text‘。眼睛閉合的時(shí)候，type=’password‘；
但是就這個(gè)切換，開發(fā)者工具調(diào)試有效的。不過在真機(jī)上，會(huì)出現(xiàn)切換那刻無效，進(jìn)而需要再次輸入一個(gè)字符時(shí)，才會(huì)變更 type值。
改進(jìn)時(shí)，ios再顯坑：
進(jìn)而有技術(shù)貼說到，避開用一個(gè)input 改變type的方法。而是使用 兩個(gè)input，type? ：一個(gè)設(shè)定為 text模式，一個(gè)設(shè)定為password模式，直接綁定好 輸入的值。眼睛的切換是對(duì)兩個(gè)input進(jìn)行來回顯示達(dá)成曲線救國(guó)。
這個(gè)想法確實(shí)很美好。經(jīng)測(cè)試Android兄弟表現(xiàn)完美實(shí)現(xiàn)了眼睛開合密碼顯示與否的交互。
但是ios兄弟出現(xiàn)了一個(gè)很奇怪的現(xiàn)象，就是當(dāng) 我由 起初的password切換到text模式，繼續(xù)進(jìn)行輸入密碼。輸入后又由text切回password模式，然后再password模式下嘗試繼續(xù)輸入密碼時(shí)，此時(shí)此刻 密碼框的值被 完全重置為 空了！
