原理介紹
Optimistic UI 是 Meteor 提出來(lái)的一種前端界面快速響應(yīng)用戶交互的概念蛙讥，之前叫 Latency Compensation翠储，主要作用是在客戶端直接響應(yīng)用戶的交互曲尸，而不用等信息從客戶端發(fā)送到服務(wù)器镇匀，完成更新確認(rèn)牙寞，再?gòu)姆?wù)器返回客戶端這一個(gè)來(lái)回完成后再做響應(yīng)葡公。有點(diǎn)類似游戲領(lǐng)域里的 Dead Reckoning罐农，在客戶端離線對(duì)用戶行為進(jìn)行推測(cè)，達(dá)到隱藏延時(shí)和減少帶寬使用的技術(shù)催什。
先看下圖理解 Optimistic UI 的原理涵亏。
魔法就發(fā)生在虛線處。簡(jiǎn)單來(lái)說(shuō) Method Call 其實(shí)有兩個(gè)蒲凶，一個(gè)在服務(wù)器端气筋，這個(gè)是起真正作用的；另外一個(gè)在客戶端旋圆，是一個(gè)模擬函數(shù)（也叫樁函數(shù) stub function）會(huì)直接對(duì)客戶端的 MiniMongo 數(shù)據(jù)庫(kù)進(jìn)行修改宠默，這樣用戶就可以立即看到界面的更新（Meteor 的 reactive 特性會(huì)讓界面根據(jù) MiniMongo 更新），而不用等上圖下半部分的藍(lán)色 Network latency 和 Data for client-side cache 過程完成了臂聋。
再來(lái)看看幾個(gè)例子光稼。
沒有使用 Optimistic UI
下圖是沒有 Optimistic UI 的時(shí)候『⒌龋可以看到任務(wù)輸入完成后過了大概 2 秒才更新艾君。這 2 秒就是模擬的前面原理圖下部的延遲。
使用 Optimistic UI
下圖是使用了 Optimistic UI肄方”ⅲ可以看到任務(wù)輸入完成后列表立即就有了改變，而我們看不到的是服務(wù)器端也靜靜地完成了更新权她，用戶只會(huì)感覺這個(gè)系統(tǒng)使用起來(lái)非常流暢虹茶，體驗(yàn)提升。
使用 Optimistic UI隅要，但是服務(wù)器端更新失敗蝴罪，前端自動(dòng)回滾
下圖是使用了 Optimistic UI，但是服務(wù)器端因?yàn)榉N種原因更新失敗的過程模擬步清∫牛可以看到任務(wù)輸入完成后列表立即就有了更新虏肾，但是大概 2 秒后因?yàn)榉?wù)器確認(rèn)更新失敗，前端界面再次更新欢搜，恢復(fù)到和服務(wù)器端同步后該有的結(jié)果封豪。當(dāng)然這個(gè)過程需要更多改進(jìn)來(lái)優(yōu)化用戶在交互失敗時(shí)的體驗(yàn)，而不是簡(jiǎn)單粗暴的回滾回初始值炒瘟。
小結(jié)
這就是 Meteor 的 Optimistic UI吹埠，一種積極樂觀的界面更新策略，它是基于我們大部分的用戶互動(dòng)都是成功的預(yù)測(cè)之上疮装。如果追求極致的用戶體驗(yàn)缘琅，達(dá)到實(shí)時(shí)更新，可以使用 Meteor 來(lái)輕松做到廓推，別的框架得另外寫很多代碼來(lái)維護(hù)這一套機(jī)制胯杭，增加工作量和出錯(cuò)機(jī)會(huì)。
