[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这么火你还没用吗？还不赶快尝试下。已经在使用了？也但愿本文能给你不同的思路

---

文中有表述不许确的或者有相关建议的欢迎在下面留言（'.'）