項目背景
剛剛參加完一個項目，背景：后端是用java，后端服務已經開發的差不多了，現在要通過web的方式對外提供服務，也就是B/S架構。后端專注做業務邏輯，不想在后端做頁面渲染的事情，只向前端提供數據接口。於是協商后打算將前后端完全分離，頁面上的所有數據都通過ajax向后端取，頁面渲染的事情完全由前端來做。另外還有一個緊急的情況，項目要緊急上線，整個web站點的開發時間只有兩周，兩周啊！於是在這樣的背景下，決定開始一次前后端完全分離的嘗試。
之前開發都是同步渲染和異步渲染混搭的，有些東西可以有后端PHP幫你編譯好，如通用的頁面模板，后端傳回的頁面參數等。提前預感到這次完全分離可能會遇到一些困難，但是項目上線要緊，也不能深入搞架構，於是打算就用jQuery+handlebars，jQuery來完成頁面邏輯和DOM操作，用handlebars來完成頁面渲染，這個方案是如此的簡單粗暴，但好處能最穩妥的保證項目按期完成。其實前后端分離並不是一件容易的工作，這么做會有諸多不完善之處，后面再談。
所謂的前后端分離，到底是分離什么呢？其實就是頁面的渲染工作，之前是后端渲染好頁面，交給前端來顯示，分離后前端需要自己拼裝html代碼，然后再顯示。前端來管理頁面的渲染有很多好處，比如減少網絡請求量，制作單頁面應用等。事情聽起來簡單，但這么一分離又會牽扯到很多問題，比如：
- 資源的按需加載。尤其是在單頁應用中。
- 頁面展現邏輯。分離讓前端的邏輯陡增，需要有一個良好的前端架構，如mvc模式。
- 數據校驗。因為頁面數據都是從后端請求來的，必須校驗要展示的數據是否合法，避免xss或其他安全問題。
- 短暫白屏。因為頁面不是同步渲染的，在請求數據完畢之前，頁面是白屏的，體驗很不好。
- 代碼的復用。眾多的模板、邏輯模塊需要良好組織實現可復用。
- 路由控制。無刷新的前端體驗同時毀掉了瀏覽器的后退按鈕，前端視圖需要有一套路由機制。
- SEO。服務端不再返回頁面，前端根據不同的邏輯呈現不同的視圖（並非頁面），要對搜索引擎友好需要做很多額外的工作。
以上每一個問題都夠棘手，要處理好需要有設計精良又符合實際項目的方案。現在已經有很多框架可以幫我們做這些事情，Backbone, EmberJS, KnockoutJS, AngularJS, React, avalon等等，利用它們可以架構起一個富前端。但框架畢竟是框架，要利用到實際項目中，還是需要有自己的設計，框架並不能解決所有的問題。
之前也有看過淘寶團隊的實踐，利用nodejs做一個中間層，處理頁面渲染、路由控制、SEO等事情，將前后端的分界線進行了重新定義。個人感覺這應該是一個正確的方向，有點顛覆的感覺，前端走向工程化，將變成真正的全棧式大前端。不知現在這種架構是否在淘寶全面鋪開，真有點期待看看效果。
以上的框架，還有淘寶的實踐，畢竟都是大牛之作，我這個小輩也只是參考學習過，未能在實際項目中使用。低頭看看自己現在手頭的項目，1個前端，2周時間，要完成一個完整的web項目，還是用最穩妥最低級的方式來搞吧~
項目整體並不是一個單頁應用，但有些模塊需要做成局部的單頁操作，像這種需要分步完成的操作，只需局部加載子頁面即可。
因此，一個模塊有一個主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文件，文件內容結構如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
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定義的代碼也放出來吧：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
//以配置的方式代理事件
$.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>標簽能夠正常加載。所以每個頁面使用頭部的代碼就變成這樣：
|
1
2
3
4
|
<script src=
"static/js/tpl/head.js"
></script>
<div id=
"header"
>
<script src=
"static/js/includeHead.js"
></script>
</div>
|
includeHead.js中的代碼如下：
|
1
2
3
4
5
6
7
|
function
includeHead(){
var
header = document.getElementById(
'header'
);
var
compileHead = Handlebars.templates[
'head'
];
var
head = compileHead({});
document.write(head);
}
includeHead();
|
看着是有點別扭，不過為了實現功能，目前也就只能這樣了。
如上面所述，jQuery的$.load()方法可以滿足加載子頁面的需求，現在需要解決的問題是，不管用戶刷新頁面還是前進后退，我們都得根據hash值來渲染對應的視圖，其實就是路由控制。這個時候就需要監聽hashchange事件了，我定義了一個loadPage方法用來加載子頁面，然后綁定監聽器如下：
|
1
|
window.onhashchange =
this
.loadPage;
|
在loadPage方法中，根據hash的值來調用$.load()方法，子頁面的初始化工作，在$.load()的回調函數中指定。
這樣做還有一個便捷之處，我們切換視圖不必手動調loadPage方法，只需要修改頁面的hash就可以了，hash發生變化被監聽到，自動加載對應的子頁面。例如，點擊下一步進入步驟二：
|
1
2
3
|
'.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，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
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可以輸出你所要查詢的參數值，然后可以直接寫在模板中，如：
|
1
|
<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。