有一段都在重構以前文章《我和個人廣告前端代碼(三):一次重來的機會,必要的技術選型》中提到的廣告前臺展現項目,原有的基於頁面的請求,改爲了單廣告位請求在這個過程當中經歷了好幾回架構變動以及項目剎車。回過頭來看看,感受收穫很大的。纔剛剛把前臺展現弄完,又開始了新的挑戰——後臺投放。css
其實原來也是有投放系統的,自從我去年接手的時候就有了一個龐大的後臺投放系統。這個系統的後臺寫的仍是很不錯的,可是因爲當時前端團隊人員較少,整個系統的頁面就變成了,前端作個靜態頁,後端套模板的實現方式了。因爲後期由後端同事孤立無援的完成,致使這頁系統的前端頁面並無想象中的好維護。先說明一下,並非說後端作出來的頁面很差,只是說最終仍是要交給前端來維護,爲了方便之後的維護,咱們必需要作些什麼。爲此我一直在思考這個問題,恰逢後臺系統有了一個新需求,不說業務,主要是要添加一個頁面來專門處理一些業務,可是有和別的業務沒什麼耦合,簡單來講,就是一個徹底新的,隨便玩兒的空白頁,風險也比較小。那麼這是一個機會來嘗試着用一些適合處理後臺系統頁面的技術來開發。下面我來介紹一下吧:html
爲何不延續原有的,直接迭代出一個頁面?前端
其實若是咱們不改變原有的,利用原有的頁面能不能拼裝出一個頁面,再加上業務邏輯,直接上線萬事大吉呢?答案確定是能夠的,雖然完成了需求可是這樣作的結果會讓很差維護的頁面變的愈來愈多。那麼原有的頁面有哪些問題呢:vue
一、模板沒有按組件爲單元切割成片斷,好多頁面上用到同一個結構,採用的方式拷貝這一段代碼到不一樣的頁面。問題也比較明顯大量重複的代碼,修改的成本比較高。node
二、js引用沒有模塊化,徹底依賴加載順序,大量內聯js。因爲上面模板的重複拷貝,致使js重複拷貝,或者爲了使用別的頁面中的某一個功能,卻引用了那個js文件。react
三、css混亂,預編譯、沒有分模塊,式樣相互覆蓋。jquery
四、數據驅動的頁面,利用jquery大量的修改DOM,大量數據寫在DOM上,js中數據走向不連貫,若是不運行調式一番,很難弄清楚數據邏輯。webpack
五、大量的第三方依賴,爲了初始化組件,所有都在頁面的一開始就運行了,很難劃分調用週期。es6
六、每次局部數據的變更,依賴的是form提交兒形成的頁面刷新。這種整個頁面的渲染,應由ajax + 局部渲染來完成。ajax僅僅是獲取局部變化的數據,而刷新請求返回的倒是整個文檔(不只僅是數據,還有後臺渲染後的html字符串),從速度上來講ajax又划算的地方,可是ajax渲染也有很差的地方,好比一旦業務模板改動,就要同時修改維護*.tpl(或*.jsp)和js中的前端模板 兩套模板。web
優化方案:
考慮到新需求是新增頁面,而不是對老頁面迭代,使用新技術方案的「推翻成本」並不高。並且新作頁面從排期上,能夠爭取到的時間也會比較充足,考慮到新技術方案帶來的高效率和調研摸索致使的時間延長,綜合來看恰好能夠完成開發。B端的頁面也不用考慮IE的兼容性,這爲使用現有主流MVVM框架提供了便利條件。接下來咱們看看如何解決這些問題:
首先這是一個B端系統的頁面,因爲大量的數據交互、DOM修改和少許的動畫特效,很容易咱們能夠想到使用某個MVVM的框架來實現需求,利用MVVM框架一方面能夠處理複雜的DOM操做帶來的性能瓶頸,另外一方面是我比較懶惰,想借用一些框架中現成的組件化思想來分割頁面實現模塊化。最終考慮到框架的可維護性和框架的輕便程度我最終考慮使用Vue來進行開發,從另外一方面來講,主要是angular1.x與2 的不兼容,而我對2也不是很熟悉;react和vue方面同爲組件化思想的框架,但vue比較小巧,中文文檔也比較豐富。
咱們一塊兒來看看針對上面的幾個問題,vue.js框架是怎麼解決的。
一、模板分割的問題:vue採用的是組件化的編程思想,我將頁面劃分爲多個獨立的組件,分別封裝到*.vue文件中。在官方文檔中也對組件間的通訊有豐富的解決方案。獨立管理組件各自的生存週期和內部的數據到模板的渲染。實現有數據驅動的自動渲染,將html的碎片封裝在js(vue)模塊中。
二、關於js的模塊,按需加載、循環引用的問題,我使用的是webpack 下ES6的方式,commonJS來管理js模塊和vue模塊
三、css我本想用less來處理,後來想的是用*.vue中對style的處理,最後合成css 的方式來嚐個鮮。
四、處理大量數據驅動模板的問題,vue的虛擬DOM方式經過計算diff後再操做DOM,會大幅提升頁面性能。
五、大量的第三方依賴:經過webpack來實現管理,控制三方庫的調用時機。
六、局部渲染的問題:不編寫後端模板,只維護前端模板並放在組件模塊的內部,ajax返回的數據直接驅動模板變化HTML,不用從新請求整個頁面,js局部渲染的工做也不用親自操做DOM,而是交給數據-模板的雙向綁定。
怎麼作的?
此次我至關於直接在一個白頁上開發,固然仍是要借用公共頭和公共尾和一些通用的導航。剩下的主題部分,就是咱們施展拳腳的舞臺了。在閱讀vue文檔的時候發現,其實vue官方提供了一個腳手架,若是你曾經用過Yeomen或者相似工具的同窗,應該不會陌生,沒錯,vue的開發團隊爲咱們提供了vue-cli來方便咱們建立一個vue的項目,官方出品,用着也放心啊。經過建立是加入不一樣的參數,建立的時候回答一些問題,你就會獲得一個基本版的vue項目。相比Browserify我對webpack更熟悉一些,因此我選用的是webpack。具體的方法傳送門。從生成的package.json 來看(下圖),主要有一下這些:ES六、瀏覽器自動刷新、式樣預編譯、js靜態檢查、node服務、webpack、自動化測試以及斷言庫、vue等等。目錄結構以下圖:
這套架構下有一個亮點,就是es6的編譯速度,咱們經常使用的gulp babel編譯速度比較慢。而這套框架中預設的編譯方式 npm script 控制一個後臺的服務,只要有文件修改,就自動編譯輸出到前臺頁面。
具體的業務實現就不說了,我在這裏簡單說一下我在此次的開發中遇到的問題和感覺到vue強大的地方吧以及一些注意事項吧:
一、web conpontents 思想:vue中將組件化的思想融入到方方面面,甚至定義了一種封裝每一個組件的文件格式—— *.vue 文件。每一個*.vue文件都由三部分組成:template、 script、 style 分別用來控制 模板、 js邏輯和式樣。其中template使用的是vue的雙向綁定的模板引擎;script中使用ES6的語法編寫,控制這個組件的數據綁定以及相關的回調函數;style中是這個組件的式樣,注意具備scoped屬性的樣式只會應用到當前元素和其子元素。
使用這套架構咱們能夠比較輕鬆的以文件爲單位來劃分組件模塊。每個模塊有本身的js和css,這樣能夠在複用模塊的時候,引入最少的代碼。
二、es6快速編譯:這一點不是vue帶來的,而是vue-cli帶來的。使用過babel的同窗通常都抱怨過編譯速度慢的問題,在使用過vue-cli中的編譯後我發現是我原來的配製方法很差,vue-cli的方案是並不生成實體文件,而是在內存中不斷編譯,經過node服務打到前臺頁面中。雖然最後build的時候和原來同樣慢,可是在調試的時候很快基本上是實時,並且即便你瀏覽器打了斷點,可是新的編譯結果也能反映到當前瀏覽器中(即便不刷新頁面或者說他會判斷是否改動的呈現是須要刷新頁面的)。畢竟build只是最後一下。
三、既然提到了build ,須要注意一點:默認的build腳本中,對於生成的靜態文件後面是帶hash的,若是你不想要,能夠在將build/webpack.prod.conf.js文件中webpack配置中的output中的「[chunkhash]」去掉便可,以下圖:
四、npm script:過去我都一直使用gulp來管理工程,可是這個vue-cli並無使用gulp,其實也能夠理解vue官方出品怎麼好依賴別人的工具。看到package.json文件的時候,我發現vue-cli使用的是npm script以下圖。
我仔細查了一下,原來npm script已經被普遍使用在各大js庫和框架中,好處在於npm的包要比gulp的插件數量多出好幾倍、npm包的更新速度比gulp插件的更新速度快(以eslint爲例先有npm包,後來纔會有團隊更新gulp-eslint)。只是咱們用gulp用的太順了。
五、父子組件:既然說到組件的劃分,一旦顆粒度小,就須要組合一些組件實現新的組件,那麼就免不了父子組件的數據通訊,我採用的方式是子對父用event、父對子使用props、子與子就先event在props。
六、計算屬性:這個是我我的比較喜歡的vue的功能,有時候咱們須要對數據適配,但計算量又不大,有要求頻繁計算,就可用vue的計算屬性「computed」來返回想要的值。
七、靜態檢查:vue-cli配置的工程中在dev命令下會有強大的靜態檢查功能,會直接輸出到瀏覽器中,指出那個文件的哪一行,有什麼錯誤,該怎麼改。就感受是有一個大神在旁邊看着我編程,稍微走偏一步,就會立刻糾正。能夠屏蔽好多語法錯誤。
八、局部渲染快:這應該是vue這一類框架都有的一個特色,就是經過計算數據變化在DOM修改層面上最小的diff,來渲染html。畢竟渲染局部所須要的數據老是小於等個頁面大文檔的,提交後,頁面刷新的體驗也很差。
總結:
此次vue開發的體驗非常奇妙,一方面感覺到vue的強大和合理,另外一方面能夠體會到vue-cli的規範和嚴謹。因爲此次開發並無覆蓋太多vue的重要特性,因此既然我已經被圈粉了,vue的研究還要繼續。