一個簡單粗暴的前後端分離方案
阿新 • • 發佈:2018-12-29
專案背景
剛剛參加完一個專案,背景:後端是用java,後端服務已經開發的差不多了,現在要通過web的方式對外提供服務,也就是B/S架構。後端專注做業務邏輯,不想在後端做頁面渲染的事情,只向前端提供資料介面。於是協商後打算將前後端完全分離,頁面上的所有資料都通過ajax向後端取,頁面渲染的事情完全由前端來做。另外還有一個緊急的情況,專案要緊急上線,整個web站點的開發時間只有兩週,兩週啊!於是在這樣的背景下,決定開始一次前後端完全分離的嘗試。
之前開發都是同步渲染和非同步渲染混搭的,有些東西可以有後端PHP幫你編譯好,如通用的頁面模板,後端傳回的頁面引數等。提前預感到這次完全分離可能會遇到一些困難,但是專案上線要緊,也不能深入搞架構,於是打算就用jQuery+handlebars,jQuery來完成頁面邏輯和DOM操作,用handlebars來完成頁面渲染,這個方案是如此的簡單粗暴,但好處能最穩妥的保證專案按期完成。其實前後端分離並不是一件容易的工作,這麼做會有諸多不完善之處,後面再談。
淺談前後端分離
所謂的前後端分離,到底是分離什麼呢?其實就是頁面的渲染工作,之前是後端渲染好頁面,交給前端來顯示,分離後前端需要自己拼裝html程式碼,然後再顯示。前端來管理頁面的渲染有很多好處,比如減少網路請求量,製作單頁面應用等。事情聽起來簡單,但這麼一分離又會牽扯到很多問題,比如:
專案整體並不是一個單頁應用,但有些模組需要做成區域性的單頁操作,像這種需要分步完成的操作,只需區域性載入子頁面即可。
因此,一個模組有一個主html頁面,初始只有一些基本的骨架,有一個名字相同的js檔案,該模組邏輯都在此js檔案中,有一個名字相同的css檔案,該模組的所有樣式都定義在此css檔案中。
需要非同步載入的子頁面,像上圖中每個步驟的頁面,我都使用jQuery的$.load()方法來載入,此方法能在頁面某個容器中載入內容,並可指定回撥函式,使用起來很方便。被非同步載入的子頁面我都用_開頭,如_step1.html,用於做區分。
為了確保瀏覽器的前進後退按鈕可用,我使用了hash來做路由標記,頁面地址如:publish.html#step2。有個缺陷是hash並不會傳送給伺服器,所以SEO就廢了。事實上使用history API也可以更優雅的解決問題,但需要考慮相容性,還有額外工作要做,考慮時間因素,退而求其次,況且本專案也無需做SEO。或者像淘寶的方案那樣,nodejs層與瀏覽器層統一路由,SEO問題可以迎刃而解。但又明顯不在本人的實力範圍之內,汗--!
除了用$.load非同步載入的子頁面,剩餘的區域性頁面就是用handlebars提供的模板渲染了,我使用了handlebars的預編譯功能,不得不說很強大,一來節約了頁面載入階段所需的編譯時間(編譯handlebars模板),二來編譯後的模板(js檔案)方便複用。
接下來就是前端邏輯如何組織,因為沒有用mv*框架,所以只能靠自己來寫一個便於開發的結構。如上面所述,每個模組有一個主js檔案,檔案內容結構如下:
- 資源的按需載入。尤其是在單頁應用中。
- 頁面展現邏輯。分離讓前端的邏輯陡增,需要有一個良好的前端架構,如mvc模式。
- 資料校驗。因為頁面資料都是從後端請求來的,必須校驗要展示的資料是否合法,避免xss或其他安全問題。
- 短暫白屏。因為頁面不是同步渲染的,在請求資料完畢之前,頁面是白屏的,體驗很不好。
- 程式碼的複用。眾多的模板、邏輯模組需要良好組織實現可複用。
- 路由控制。無重新整理的前端體驗同時毀掉了瀏覽器的後退按鈕,前端檢視需要有一套路由機制。
- SEO。服務端不再返回頁面,前端根據不同的邏輯呈現不同的檢視(並非頁面),要對搜尋引擎友好需要做很多額外的工作。
var publish = { //該模組初始化入口 init : function(){ this.renderData(param); this.initListeners(); }, //內部所用的函式 renderData : function(param){ //渲染資料。。 }, //統一繫結監聽器 initListeners : function(){ $(document.body).delegates({ '.btn' : function(){ //點選事件 }, '.btn2' : function(){ //點選事件2 }, '.checkbox' : { 'change' : function(){ //change事件 } } }); } }每個模組給一個名稱空間,所有的方法都掛在上面,js檔案中只做函式的定義,不立即執行任何東西,然後在html檔案中呼叫入口方法:publish.init()。業務邏輯都封裝到函式中,如上面的renderData,然後供其他地方呼叫。頁面的事件監聽器統一都註冊在body元素上,用事件代理來完成,為了避免寫太多的on、click之類程式碼,為jQuery擴充套件了一個delegates方法,用來以配置的方式統一繫結監聽器,用法如上所示。把delegates定義的程式碼也放出來吧:
//以配置的方式代理事件 $.fn.delegates = function(configs) { el = $(this[0]); for (var name in configs) { var value = configs[name]; if (typeof value == 'function') { var obj = {}; obj.click = value; value = obj; }; for (var type in value) { el.delegate(name, type, value[type]); } } return this; }基本的結構就是這樣,沒有什麼新技術,只是把現有的東西做了一下組合。但工作到此還遠遠沒有結束,在實際應用中還會有一些東西需要處理,下面來詳細說說: 公共頭部底部的引用 這是一個比較棘手的問題,一般通用的頭部和底部會放一些公共的程式碼,如頁面外層結構html程式碼,站點使用的庫如jQuery、handlebars,站點通用js和css檔案。在傳統的開發中,通常是寫一個單獨的檔案如head.html,在其他頁面中用後端程式碼如include語句引入,由此來進行復用。 現在前後端分離後,無法依靠後端來給你渲染,所以得在前端做了。既然用了handlebars,很容易想到把公用部分寫成一個模板,然後預編譯出來,生成一個header.js檔案,然後在其他頁面引用。然而在實際操作中發現了一個問題,handlebars是靜態模板,編譯後生成的字串通過innerHTML的方式插入到頁面,在一般的模板中這樣是沒問題的。現在有個問題是header中有一些<script>標籤,外鏈著要使用的庫,通過innerHTML插入<scirpt>標籤,瀏覽器並不會傳送請求載入對應的js檔案,所以就出問題了。 搜尋、嘗試了多種方法後,最終的方案定為:用document.write()將編譯結果寫到頁面,這樣<script>標籤能夠正常載入。所以每個頁面使用頭部的程式碼就變成這樣:
<script src="static/js/tpl/head.js"></script> <div id="header"> <script src="static/js/includeHead.js"></script> </div>includeHead.js中的程式碼如下:
function includeHead(){ var header = document.getElementById('header'); var compileHead = Handlebars.templates['head']; var head = compileHead({}); document.write(head); } includeHead();看著是有點彆扭,不過為了實現功能,目前也就只能這樣了。 ----------補充於 2015.1.27--------------- 雖然用原生的innerHTML無法載入<script>標籤中的內容,但是jQuery的$().html()方法進行了優化,可以查詢到<script>標籤並且執行裡面的程式碼,所以用$().html()是可以完成上面的工作的。 這麼一看,這個蹩腳的方案就可以替換了。 路由控制 如上面所述,jQuery的$.load()方法可以滿足載入子頁面的需求,現在需要解決的問題是,不管使用者重新整理頁面還是前進後退,我們都得根據hash值來渲染對應的檢視,其實就是路由控制。這個時候就需要監聽hashchange事件了,我定義了一個loadPage方法用來載入子頁面,然後繫結監聽器如下:
window.onhashchange = this.loadPage;
在loadPage方法中,根據hash的值來呼叫$.load()方法,子頁面的初始化工作,在$.load()的回撥函式中指定。
這樣做還有一個便捷之處,我們切換檢視不必手動調loadPage方法,只需要修改頁面的hash就可以了,hash發生變化被監聽到,自動載入對應的子頁面。例如,點選下一步進入步驟二:
'.next' : function(){ location.href = '#step2'; }如此便實現了一個簡單的路由控制,由於不是整站單頁面,也沒有多級路由,這樣完全可以滿足需求。至於SEO,就只能呵呵了,正好專案也不需要做SEO,否則此方法得作罷。 另外想說的一點就是頁面的快取,非同步載入來的內容可以存在localStorage中,也可以放在頁面上進行顯隱控制,這樣使用者在頻繁切換檢視的時候無需再次請求,回到上一步的時候之前填好的表單資料也不會消失,體驗會非常好。 頁面間引數傳遞 有時候我們需要給訪問的頁面傳引數,比如訪問一個裝置的詳細資訊頁,要把裝置id給傳過去,detail.html?id=1,這樣detail頁面可以根據id去請求對應的資料。傳統由後端渲染的頁面,url中的引數會發送到服務端,服務端接收後可以再渲染到頁面上供js使用。我們現在不行了,請求頁面壓根不跟後端打交道,但這個引數是必不可少的,所以需要前端有一套傳遞引數的機制。 其實非常簡單,通過location.href可以拿到當前的url地址,然後進行字串匹配,把引數提取出來就可以了。看上去挺土鱉的,但工作起來良好,另外也有考慮過用cookie來傳遞,感覺有點麻煩。 由於這些引數通常是寫在<a>標籤上的,而<a>標籤又是根據動態資料渲染出來的(因為是動態引數),我們不可能在頁面渲染完後,用js修改所有<a>標籤的href值,給它追加一個引數。怎麼辦呢?這時候handlebars就派上用場了,我們可以使用handlebars萬能的helper,在渲染頁面的時候直接查詢url中的引數,然後輸出在編譯好的程式碼中。我在handlebars中註冊了一個helper,如下:
Handlebars.registerHelper('param', function(key, options){ var url = location.href.replace(/^[^?=]*\?/ig, '').split('#')[0]; var json = {}; url.replace(/(^|&)([^&=]+)=([^&]*)/g, function (a, b, key , value){ try { key = decodeURIComponent(key); } catch(e) {} try { value = decodeURIComponent(value); } catch(e) {} if (!(key in json)) { json[key] = /\[\]$/.test(key) ? [value] : value; } else if (json[key] instanceof Array) { json[key].push(value); } else { json[key] = [json[key], value]; } }); return key ? json[key] : json; });這個名為param的helper可以輸出你所要查詢的引數值,然後可以直接寫在模板中,如:
<a href="detail.html?id={{param id}}">裝置詳細資訊</a>這樣就方便多了!但是這麼做有沒有問題呢?其實是有些不完美的,如果你考慮“效能”二字的話。一個url中引數的值是固定的,而你每次使用這個helper都會計算一遍,白白做了多餘的事情。如果handlebars可以在模板中定義常量就好了,可惜我找遍文件沒發現有這個功能。只能為了方便犧牲效能了,也正印證了我標題中所說的“簡單粗暴”,呵呵。 資料的校驗和處理 由於資料是由後端傳來的,有很多不確定性,資料可能不合法,或者結構有錯,或者直接是空的。因此前端有必要對資料做一個合法性的校驗。藉助handlebars,可以很方便的進行資料校驗。沒錯,就是利用helper。handlebars內建的helper如if、each都支援else語句,出錯資訊可以在else中輸出。如果需要個性化的校驗,我們可以自己定義helper來完成,關於如何自定義helper,我之前研究了下,寫過一篇文章:http://www.cnblogs.com/lvdabao/p/handlebars_helper.html。總之自定義helper很強大,可以完成你所需的任何邏輯。 資料的格式化,如日期、數字等,也可以通過helper來完成。 另外一方面,前端還應對資料進行html轉義,避免xss,由於handlebars已經給做了html轉義,所以我們可以直接忽略此項了。 總結 本文是我剛剛參加完一個專案後所寫,記錄一下整個過程遇到的問題及處理方式,其他的一些細碎點如表單非同步提交什麼的,不是本文重點,不寫了。這是我第一次實踐前後端完全分離的專案,整個前端全由我來設計、開發。2周時間,憑著這套方案,專案按期開發完成,而且還提前完成了,預留出一天多的時間測試了一遍。 雖然開發任務是完成了,但是回頭看一下整個方案,並不是很優雅也沒有什麼技術含量,文章開頭提到的幾個問題都沒有解決。所以命題為簡單粗暴的方案,都是為了趕工期啊。 最後,如果給我再來一次的機會,並且時間充足,我一定要嘗試用mv*方案來搞一下,或angular,或avalon。