阅读 3581

[webpack]中小型多页面应用整合webpack终极方案

现在前端模块化、es6、MVVM这么火,附带的在学习使用这些知识时或多或少都会接触到webpack。 这里我不会去讲webpack本身的知识,这些东西都烂大街了一搜一大把。

通过本文你将会了解到如何将webpack引入到一个传统的多页面项目(如:商城)中去,借助webpack让我们能够使用es6、能够实现我们的模块化方案

注意:仅指中小型多页面项目

一,传统多页面的特点

  • 一个页面对应一个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这么火你还没用吗?还不赶快尝试下。已经在使用了?也希望本文能给你不一样的思路


文中有表述不准确的或者有相关建议的欢迎在下面留言('.')

关注下面的标签,发现更多相似文章
评论