這篇PPT是關于最近在做H5版杭州公交的經(jīng)驗分享,里面部分細節(jié)也包括工作一年的總結晓锻。
簡介
Vue是我在8月份第一次接觸熊户,用周末兩天時間熟悉了下API及Vue全家桶布卡,框架學完練練手可以熟悉思路,在之后的項目中能馬上使用到卧惜。所以我將我的博客從Angualr1.3改寫到Vue1.0厘灼,花了不少下班時間夹纫。項目是由vue-cli基礎上開發(fā),現(xiàn)已在GitHub上開源设凹,另外還包括對博客支持的后臺代碼舰讹,使用的是Node+Express+Mongodb。
之后Vue2.0發(fā)布后闪朱,趁著項目測試的空隙月匣,又將博客升級到2.0,改動的部分及總結在博客中已寫出奋姿,可以作為升級的參考,鏈接称诗。到目前為止萍悴,已經(jīng)使用Vue直接開發(fā)了3個項目,加上今天的分享寓免,應該是第四個了癣诱。因為Vue對瀏覽器的唯一的限制是IE9+,故移動端應該是沒問題的袜香。
目錄
這個是ppt的順序撕予,有些思路可能某些同學沒接觸過,我也是用比較形象的方式給大家講解蜈首。我希望以后大家在學到新的東西都能通過這種方式分享出來共同進步实抡,回顧總結,加深自己的印象疾就。
如何選擇框架
這里主要是我對我已有的經(jīng)驗來分析如何根據(jù)項目來選擇框架∫蘸可能由我的局限性猬腰,希望能和大家碰撞下思想。
1. 對于后臺管理系統(tǒng)
我曾經(jīng)使用過兩次jQuery+ifream框架(二次維護猜敢,歷史遺留問題)姑荷,通過接口獲取數(shù)據(jù)后拼接HTML字符串然后append到DOM中,因為需求沒有設計成UI缩擂,當時拿到的是功能清單鼠冕,UI只能靠我們前端自己設計。因此在寫render函數(shù)之前胯盯,我將畫好的UI給leader看懈费,然后討論交互,連問多遍有沒問題后才敢開始寫render函數(shù)博脑,因為需求改動后憎乙,render函數(shù)就會廢棄再寫票罐!不過最后結果還好,返工的不多泞边。另一個是給后臺寫jsp模板该押,分不清前后端界線,js交互也不敢多寫(后端同學理解JS也是頭疼)阵谚。
以上蚕礼,也許也能看出問題點了,代碼無法復用梢什,需求改動后代碼改動多奠蹬;前后端界線不清,工作內容會有重疊绳矩,口頭確認不是很好的規(guī)范罩润。所以我傾向于基于MVVM模式的SPA系統(tǒng)。前后端由API文檔劃分界線翼馆,因為不涉及到首次加載速度割以、瀏覽器適配范圍和SEO等問題,我認為SPA的方式是可行的应媚,也是大多數(shù)公司在用的方式严沥,例如阿里云控制臺、收錢吧控制臺中姜、盈聯(lián)智能商戶管理系統(tǒng)等消玄。
2. 對于面對消費者的PC頁面
這種場景,使用后端渲染的方式無可厚非丢胚,加載快翩瓜,利于SEO,頁面可緩存等優(yōu)點携龟。
3. 移動端展示類型的頁面
這種情況大多數(shù)不會超過5個頁面(類似于抽獎兔跌、活動展示、答題峡蟋、留言板等)坟桅,且頁面間銜接的緊密度不高,使用zepto框架即可蕊蝗。開發(fā)快速仅乓,a標簽跳轉,如果不喜歡300ms點擊延遲蓬戚,那就上fastclick就好夸楣,一般開發(fā)人員就能勝任。
4. 移動微應用
最后一個場景就是較為復雜的移動微應用,古老的方法是使用后端渲染的方式進行裕偿,例如jsp洞慎、hbs等,如果不同頁面間數(shù)據(jù)需要傳遞也只能放到url中或者sessionStorage或者localStorage中嘿棘,開發(fā)邏輯不好維護劲腿,需要加大量的注釋。頁面跳轉還需要再次加載公共的腳本鸟妙,如果服務器開了緩存還好焦人,否則用戶體驗不好。我這里傾向于使用SPA模式開發(fā)重父,由路由控制增量加載的內容(懶加載)花椭,webpack進行代碼分割,確保首屏之外的資源按需加載房午。前端控制范圍增多矿辽,API劃分界限。
MVC和MVVM對比
Vue是基于MVVM開發(fā)模式的框架郭厌。在MVVM之前還有很多開發(fā)模式袋倔,不過都被踩在時代的腳下,比如MVC折柠。就我經(jīng)驗所及的范圍宾娜,我認為MVVM在處理UI交互方面應該是抽象的最全面的模式。
上張圖是MVVM的結構扇售,在SilverLight或者WPF開發(fā)中常用的模式前塔,同理,前端也是和UI交互的部分承冰,模式借鑒很有意義华弓。View層只依賴數(shù)據(jù),降低View-Model與View之間的耦合困乒;只要數(shù)據(jù)相同寂屏,View-Model可復用,UI測試轉化為對Data的測試顶燕。
jQuery是MVC開發(fā)模式的一個代表凑保。在jQuery代碼中冈爹,controller中存在大量的和view耦合的邏輯涌攻,例如jq中的html片段拼接,無法復用和維護困難频伤。另外恳谎,controller基本沒有測試的可能。
MVC和MVVM業(yè)務實現(xiàn)區(qū)別
1. MVC方式
以我現(xiàn)在在做的頁面對MVC和MVVM做個對比。
頁面1是第一次的需求因痛,我按照頁面將HTML片段和數(shù)據(jù)拼接寫好render函數(shù)婚苹,之后append到頁面中,數(shù)據(jù)通過ajax獲取鸵膏。當UED改圖時(頁面2)膊升,可以看出頁面的結構發(fā)生了變化:由之前的上下結構變成了左右結構,對用的HTML片段也要發(fā)生變化谭企,故render函數(shù)需要修改以適應新需求廓译,我醉了。债查。非区。這種需求以前遇到很多回了!view和controlelr高度耦合盹廷,并且HTML片段不易再次維護征绸,不可測試也無法復用。
2. MVVM方式
如果頁面是使用MVVM模式做的話俄占,從上面可看出管怠,頁面的數(shù)據(jù)是沒變動的,只是HTML變動颠放,故使用Vue雙向綁定的基礎功能排惨,我這里只需要修改HTML即可,View-Model中的代碼無需修改碰凶。另外暮芭,只要數(shù)據(jù)格式?jīng)]問題,頁面的渲染效果也固定欲低,可測試辕宏。之后講解下代碼復用部分。
3. View-Model代碼復用
換乘摘要[1]砾莱、換乘詳情[2]瑞筐、換乘地圖[3]三部分的頁面有公共個數(shù)據(jù)部分:URL參數(shù)(起始終止位置信息+換乘策略信息)、當前策略下?lián)Q乘信息(allData -> 包含起止經(jīng)緯度腊瑟、摘要和詳情)聚假,換乘地圖獨用transferMap。因此闰非,此部分的View-Model可復用膘格,只需要判斷path后開啟必要的部分即可。
以上就是MVVM的三個優(yōu)點:低耦合财松、可復用瘪贱、可測試纱控、易維護。
Vue性能
我一般在使用Vue都是在做移動端開發(fā),既然選用是看中他的兩個特性:運行快+加載快;上圖是Vue2.0的綜合性能對比圖冤灾,右邊是Benchmark跑分(不服跑跑分),綠色越深代表越好尔店。紅框圈出的部分從左到右依次是react、Vue2.0主慰、原生JS闹获。想必大家能看出來差異了。值得一說的是河哑,Vue2.0是基于更快的Virtual-DOM避诽。
Vue構建大型項目及生態(tài)
Vue在構建大型項目也不遜色,因為Vue.js自身只是處理View層的框架璃谨,做大型項目需要協(xié)同插件的協(xié)助沙庐,這個與react很像〖淹蹋可以說Vue構建大型項目的插件都已完備拱雏。參見上圖。
我為什么使用Vue
最后說下我為什么傾向于使用Vue底扳。我認為铸抑,工具的價值在于為人服務。Vue及其附屬的Vue-cli工具很好的在開發(fā)者體驗和最終生成代碼之間做好了橋梁衷模,即:說明文檔詳細鹊汛,代碼編寫簡單,API抽象到位方便別人閱讀阱冶,最終代碼運行高效刁憋。
另外,框架的選擇取決于團隊的水平木蹬,Vue還是很簡單的至耻,而且還是中文文檔哦。
最后
用了Vue镊叁,我可以正常下班了
以上內容的更新請查看我的博客尘颓,點這里。
(完)