[webpack]中小型多頁面應用整合webpack終極方案

如今前端模塊化、es六、MVVM這麼火，附帶的在學習使用這些知識時或多或少都會接觸到webpack。 這裏我不會去講webpack自己的知識，這些東西都爛大街了一搜一大把。

經過本文你將會了解到如何將webpack引入到一個傳統的多頁面項目（如：商城）中去，藉助webpack讓咱們可以使用es六、可以實現咱們的模塊化方案

注意：僅指中小型多頁面項目

一，傳統多頁面的特色

• 一個頁面對應一個url
• 功能串插混亂，一個頁面要引入不少執行不到的代碼
• 開發和版本迭代時代碼管理難度大
• 使用文件hash控制緩存難度大，使用版本號控制緩存發佈時又會出現各類緩存更新問題

二，思考

• 功能複用和代碼組織經過模塊化的方式很容易解決這個痛點
• 多url頁面如何引入帶hash的資源文件
  • 使用webpack單入口的方式？最終致使的結果是單個資源文件過大，沒法有效利用緩存也會致使單次文件下載時間過長，因此不可取
  • 使用webpack多入口的方式？多url對應多入口貌似頗有搞頭

如今問題又來了，使用多入口一定設計到拆分的概念，將本來一個入口拆分紅多個入口這須要一個什麼樣的標準呢，這就是接下來要講的核心內容了

三，解決方案

有後端開發（如php）經驗的同窗知道在寫業務邏輯代碼時主要涉及到的是MVC中的C層（controller）,controller中會實現一系列的action，controller/action的組合也就實現了咱們的頁面url(www.xxx.com/controllerName/actionName)

1，如今咱們來捋一捋上面的過程

• 一個controller裏面會有多個action
• controller/action 對應一個url頁面
• controller/* 表示一系列處於同一個controlelr下的url頁面
• controller表示有業務關聯的一系列url頁面

如今不知道你們有沒有理解清楚，後端將有業務關聯的action寫到同一個controller中，因此前端同理能夠將有業務關聯的多個url頁面打包起來當作一個SPA應用（文中提到的SPA非真正的SPA，只是用來幫助理解）

2，開始拆分了（以商城系統爲例）

• 首頁SPA（首頁比較重要通常獨立出來）
• 商品SPA(商品詳情頁，商品列表，商品搜索頁)
• 購物車SPA(購物車列表，付款頁，結算頁)
• 用戶SPA（登陸，註冊，找回密碼一系列）
• 會員中心SPA（通常的商城會員中心功能比較簡單能夠不用拆分，若是比較複雜本身能夠按照一樣的思路進行拆分）
• 促銷SPA（視商城的業務定）
• 活動頁（活動頁通常不建議進行打包，可單獨使用傳統的方案）

這樣咱們就把商城這一個按業務拆分爲多個（首頁、商品、購物車、用戶、會員中心、促銷...）

3,一圖勝千言

隨手畫的，哈哈哈~

4，項目目錄結構

5，webpack入口配置

總結

從頭看一下整個過程

• 按業務將整個系統拆分爲多個前端項目（SPA）
• 打包SPA包含的url頁面代碼

整個過程經歷了從一到多，再從多到一

webpack這麼火你還沒用嗎？還不趕快嘗試下。已經在使用了？也但願本文能給你不同的思路

---

文中有表述不許確的或者有相關建議的歡迎在下面留言（'.'）