微信錢包內的58到家全新首頁已經上線，感興趣的同學們可以在微信中打開“我的->錢包->58到家”查看。
58到家全新首頁提出重構主要是為了解決以下問題：
- 每個城市開通的服務項目不同，有些內容是寫死在tpl中，維護非常頭疼；
- 開通新服務或者某些UI調整（比如更換服務項的圖片造成更改雪碧圖）時必須走代碼上線流程；
- 原有的前端切圖、后端寫邏輯的開發模式造成開發周期拉長和上線流程繁瑣；
- 原有配置后台操作復雜，且可配置細節不完善；
- 首頁加載速度太慢，用戶體驗欠佳。
58到家目前兩年左右的發展期，整個技術生態還不完善。以上的問題有的是由於創業初期遺留的歷史原因造成，比如代碼寫死和粗糙的配置后台；而有的問題是由落后的開發模式和協作模式造成的，比如前后端分工不明確、首頁加載速度慢。
基於上文提到的問題，重構從以下幾方面入手：
- 完善配置后台，細化可配置項；
- 數據驅動UI，輕量化tpl，內容更新無需上線流程；
- 前后端分離，縮短開發周期，簡化上線流程；
- 模塊化開發，提高加載速度，同事增強代碼的可維護性。
配置后台可以理解為一個簡易的CMS系統，配置的內容是一些量化的字段，比如圖片地址、鏈接、價錢等等。此項目中本人並不負責配置后台的開發，所以不再班門弄斧。
下面詳細描述重構過程中前端的解決方案。
1. 技術選型
根據上文提到的問題，此項目中前端的技術選型如下：
-
客戶端（瀏覽器）
- 使用Vue作為渲染框架（數據驅動UI）；
- 圖片懶加載使用Vue-lazyload實現；
- 模塊化方案使用CommonJS；
- 因為首頁沒有很多的用戶交互功能，大部分是鏈接跳轉，所以不使用第三方的touch event工具；
-
開發環境
- 使用58到家前端工程框架boi作為開發和構建工具；
看到以上的技術選型，可能會有讀者疑惑：不就是一個前端模板+模塊化方案嗎，有什么值得介紹呢？
首先，以上的技術選型的背景如下：
- 目前58到家FE團隊統一使用vue作為開發框架，組件易復用；
- 此次重構后的58到家首頁並非SPA，選用vue的另外一個原因是為了后續的SPA化做預備；
- 客戶端渲染html的缺點是首次進入頁面加載較慢，但利用瀏覽器緩存機制可以另再次進入頁面的加載時間大大縮短；
- 選用CommonJS實現按需加載（load on demand），首屏以外的內容在首屏渲染完成之后加載；
- boi是58到家前端工程框架，以webpack為構建內核，選用CommonJS另一個原因是webpack的原生支持。
2. 前后端分離方案
目前58到家的前后端協作模式仍然很原始，本次重構采用的前后端分離方案並非是最優解，只能算是一種折中的過渡方案。總結有以下幾點：
- 初始tpl中包含以下部分：
- js、css引用；
- 頁面初始數據；
- vue組件容器；
- 統計用初始數據。
- 客戶端采用vue作為渲染html；
- js和css更新時，FE獨立部署靜態文件，RD需要將url更新時間戳；
下面分別簡單描述以上的幾點。
2.1 輕量化tpl
tpl的內容如下：
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no">
<title>58到家</title>
<link rel="stylesheet" href = "http://static.daojia.com/assets/project/wx_index/style/main.wx-index.css?2016082001">
</head>
<body>
<div class="window">
<app :data="data"></app>
</div>
<script type="text/javascript">
// initial page data
var pageData = {};
</script>
<script type="text/javascript">
// for traker
var bi_params = {pagetype:'activity'};
</script>
<script src="https://static.daojia.com/bi/buried_point/js/tracker.js"></script>
<script src='http://static.daojia.com/assets/common/js/zepto.min.js'></script>
<script src='http://static.daojia.com/assets/common/js/vue.min.js'></script>
<script src = "http://static.daojia.com/assets/project/wx_index/js/main.wx-index.js?2016082001"></script>
</body>
</html>
-
tracker.js、zepto.min.js、vue.min.js是依賴的第三方文件，全局變量bi_params是bi統一用的初始字段； -
<app :data="data"></app>是vue組件的容器； -
tpl文件由RD維護，以上提到的兩點是固定不變的，不需要維護。RD需要維護的包括：
main.wx-index.js和main.wx-index.css的時間戳；- 全局變量
pageData。這是首屏的初始數據，之所以選擇以全局變量的方式暴露，而不是請求api，是為了減少一次http請求，盡快渲染首屏。
tpl輕量化是為了減少FE和RD的耦合，當然最佳的方式是tpl交由FE維護，但是目前58到家的開發模式並不適合。所以采用了折中的過渡方案。
使用url query作為js和css文件的緩存策略也並非最優解，理想的方案是使用hash指紋。但是hash指紋需要FE在編譯完成之后將hash值告知RD，而時間戳可以任意修改成與當前不同的值即可，減輕了溝通成本和失誤率。
2.2 客戶端渲染
選擇客戶端渲染有以下幾個優點：
- tpl輕量化，前后端解耦；
- 初始html數據量非常小，能夠快速到達客戶端。采用一些loading交互盡快給用戶視覺反饋；
- js文件初次請求之后緩存到本地，只要不更新版本，后續每次進入頁面后初次請求的數據就只有少量的html數據；
- 減小服務器（解析模板）壓力；
當然客戶端渲染也有一些缺點，比如：
- 性能比較差的設備執行渲染過程吃力，不過按照目前手機的迭代速度，這一點基本可以忽略不計；
- SEO不友好。但是這個項目是微信錢包的服務，並不直接提供外部瀏覽器入口，SEO可以不考慮。
具體到客戶端渲染的技術選型，其實從實現功能上來講隨意選用一種js模板工具即可，比如artTemplate。最終選擇vue的原因有以下幾點：
- 數據驅動UI的方式利於編寫清晰的邏輯；
- 為后續迭代做預備。后期有計划將整站SPA化，vue+vuex是比較不錯的技術選型；
- 58到家FE團隊統一使用vue，部分業務組件可復用；
2.3 更新和緩存策略
此次重構采用的緩存策略仍然比較原始，比如前文提到的url加query的方式。這也是后續有待優化的一個重點。
3. 模塊化方案
3.1 客戶端模塊化方案
58到家首頁的內容非常多，大部分尺寸的手機需要三屏才能加載完成。一次性加載的用戶體驗肯定不太順暢，按照主流的手機尺寸，將整站分成三部分：首屏+次屏+尾屏。基本的加載流程如下圖：
簡單概括如下：
- 用戶進入頁面后，客戶端發起第一次請求，服務端返回包含首屏json數據的html文檔；
main.wx-index.js根據首屏json渲染首屏；- 首屏渲染完畢之后或者用戶scroll到頁面底部觸發次屏js文件
wx-index.themes.js的加載； wx-index.themes.js加載成功后發起jsonp請求次屏和尾屏數據；- 渲染次屏；
- 次屏渲染完成之后或者用戶scroll到頁面底部觸發尾屏js文件
wx-index.tail.js的加載； wx-index.tail.js加載成功后渲染尾屏；- 至此，流程結束。
次屏的wx-index.themes.js和尾屏的wx-index.tail.js是按需加載的，是為了減少首屏的請求數和數據體積。
按需加載功能使用require.ensureAPI實現。之所以選擇使用它有以下幾點考慮：
- 58到家前端工程框架boi構建內核基於webpack，webpack runtime內置
require.ensureAPI的支持，不需要額外的模塊化工具； - AMD方案（比如require.js）的按需加載模塊不能定義模塊名稱（
wx-index.themes.js的themes，wx-index.tail.js的tail），而require.ensure則可以定義模塊名稱，使文件名更語義化；
下面簡單介紹一下如何結合vue和require.ensure實現按需加載和動態組件。
3.1.1 vue結合require.ensure實現按需加載和動態組件
回顧上文的tpl代碼可以看出，頁面整體是一個vue組件。頂層組件是<app></app>。首屏組件是第一級子組件，次屏是第二級子組件，尾屏是第三級子組件。整體結構如下圖：
vue實現按需加載動態組件要考慮以下幾點：
- 組件容器位置；
- 組件數據如何傳遞。
對比上圖可以看出子組件容器的位置：
- Themes組件作為第一級子組件App的一個子組件，容器位置如下代碼：
<div class="main"> <!-- activity banner --> <wx-activity v-if="data_activity" :data="data_activity"></wx-activity> <!-- nav --> <wx-nav v-if="data_nav&&data_nav.length!==0" :data="data_nav"></wx-nav> <!-- headline --> <wx-headline v-if="data_headline&&data_headline.length!==0" :data="data_headline"></wx-headline> <!-- service --> <wx-service v-if="data_service" :data="data_service" :test="test"></wx-service> <!-- fresh --> <wx-fresh v-if="data_fresh" :data="data_fresh"></wx-fresh> <!-- banner --> <wx-banner v-if="data_banner&&data_banner.length!==0" :data="data_banner"></wx-banner> <!-- themes --> <div class="wx-index__themes"> <themes></themes> </div> <wx-footer :notice="data.showReddot"></wx-footer> </div> - Tails組件作為第二級子組件Themes的一個子組件，容器位置如下代碼：
<template> <template v-for="theme in data.themes"> <slider v-if="theme.type==='slider'" :data="theme"></slider> <single-slider v-if="theme.type==='singleSlider'" :data="theme"></single-slider> <list v-if="theme.type==='list'" :data="theme"></list> <grid v-if="theme.type==='grid'" :data="theme"></grid> </template> <div class="tail"> <tail></tail> </div> </template>
wx-index.themes.js加載成功，在渲染Themes組件之前需要請求次屏的數據，jsonp請求放在vue組件的activate鈎子函數內：
activate: function(done) {
let _this = this;
let _url = '/home/ajaxGetSecondIndexPage';
let _cityId = pageData.cityId||$.fn.cookie('comm_cityid');
let _openId = pageData.openId||'';
$.ajax({
url: _url,
data: {
cityId: _cityId,
openId: _openId
},
dataType: 'jsonp',
success: function(res){
if(!res||!res.data){
return;
}
_this.data = Object.assign({},res.data);
// 將底部固定模塊的數據寫入全局變量，以便懶加載所需
window.dj_index_data_tail = Object.assign({},{
layidle: _this.data.layidle,
recommend: _this.data.recommend
});
},
complete: function(){
done();
}
});
}
vue組件在
activate鈎子函數返回done()之后才會繼續執行后續工作。
請求成功之后將返回的數據賦值給vue組件的data，然后vue根據data渲染UI。
上述代碼有一點需要注意。大家看到代碼將一些數據賦值給了全局變量window.dj_index_data_tail，這些數據是尾屏的數據。由於尾屏的數據量比較小，所以與次屏的數據合並成一個API。這個全局變量是為了尾屏的Tail組件渲染使用。這就是上文提到的“組件數據如何傳遞”。
使用全局變量傳遞數據的方式固然不是很優雅，但是不失為一個適合快速開發的方案。這也是后續迭代的優化點之一。
次屏渲染完畢之后觸發尾屏的加載，這個行為實在Themes組件的ready鈎子函數內進行，如下：
ready: function(){
let loadTail = function() {
if(!window.isTailLoaded){
// 主題推薦位渲染完成之后加載底部模塊
require.ensure([], function(require) {
require("../../_tail.js");
}, 'tail');
window.isTailLoaded = true;
}
};
loadTail();
}
由於之前將Tail組件的數據儲存在全局變量中，Tail組件的activate鈎子函數內可以直接讀取次全局變量：
activate: function(done){
this.data_layidle = window.dj_index_data_tail.layidle&&Object.assign({},window.dj_index_data_tail.layidle);
this.data_rec = window.dj_index_data_tail.layidle&&Object.assign({},window.dj_index_data_tail.recommend);
done();
}
以上，便完成了整個頁面的按需加載流程。當然，每種方案都不是最優解，但都是適用於目前狀態的一種比較好的方案，后續迭代中持續優化。
3.2 開發環境模塊化方案
開發環境的模塊化方案比較隨意，借助於boi框架中的babel模塊，可以將新規范的語法編譯為瀏覽器適用的語法。
此次重構的開發環境的模塊化開發使用的是ES6 Modules，語法簡潔易懂，並且開發環境沒有加載動態模塊的需求，靜態的ES6 Modules完全適合。
插播廣告：58到家前端工程框架boi支持多種模塊化方案，包括ES6 Modules、CommenJS和AMD。
4. 后續迭代需求
依前文所述，本次重構中的仍然有很多問題，這些問題是后續迭代中急需解決的。總結如下：
-
工作流程優化
- 進一步解耦tpl層，實現前后端完全分離；
-
代碼優化
- 優化緩存策略，使用hash指紋代替url query；
- 優化vue組件間數據傳遞；
- 后台可配置化引起的零散圖片太多的問題；
-
用戶體驗優化
- 添加初始loading效果，增強用戶體驗；
5. 總結
58到家微信錢包重構項目告一段落，其中采用的諸多解決方案中有好的也有不好的。不過總體來說，此次重構中58到家技術團隊向前端工程化、前后端分離邁出了標志性的一步。后續需要做的事情還很多，不論從項目本身，還是從團隊整體架構的角度，都有很大的進步空間。也歡迎各位同行提出意見和建議。