3-10 管理多个单页应用
引入问题
上一节3-9为单页应用生成HTML中只生成了一个 HTML 文件,但在实际应用中一个完整的系统不会把所有的功能都做到一个网页中,因为这会导致这个网页性能不佳。 实际的做法是按照功能模块划分成多个单页应用,每个单页应用生成一个 HTML 文件。并且随着业务的发展更多的单页应用可能会逐渐被加入到项目中去。
虽然上一节已经解决了自动化生成 HTML 的痛点,但是手动去管理多个单页应用的生成也是一件麻烦的事情。 来继续改造上一节的例子,要求如下:
- 项目目前共有2个单页应用组成,一个是主页
index.html
,一个是用户登入页login.html
; - 多个单页应用之间会有公共的代码部分,需要把这些公共的部分抽离出来,放到单独的文件中去以防止重复加载。例如多个页面都使用一套 CSS 样式,都采用了 React 框架,这些公共的部分需要抽离到单独的文件中;
- 随着业务的发展后面可能会不断的加入新的单页应用,但是每次新加入单页应用不能去改动构建相关的代码。
在开始前先来看看该应用最终发布到线上的代码。
login.html
文件内容:
<html>
<head>
<meta charset="UTF-8">
<!--从多个页面中抽离出的公共 CSS 代码-->
<link rel="stylesheet" href="common_7cc98ad0.css">
<!--只有这个页面需要的 CSS 代码-->
<link rel="stylesheet" href="login_e31e214b.css">
<!--注入 google_analytics 中的 JS 代码-->
<script>(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');</script>
<!--异步加载 Disqus 评论-->
<script async="" src="https://dive-into-webpack.disqus.com/embed.js"></script>
</head>
<body>
<div id="app"></div>
<!--从多个页面中抽离出的公共 JavaScript 代码-->
<script src="common_a1d9142f.js"></script>
<!--只有这个页面需要的 JavaScript 代码-->
<script src="login_f926c4e6.js"></script>
<!--Disqus 评论容器-->
<div id="disqus_thread"></div>
</body>
</html>
构建出的目录结构为:
dist
├── common_029086ff.js
├── common_7cc98ad0.css
├── index.html
├── index_04c08fbf.css
├── index_b3d3761c.js
├── login.html
├── login_0a3feca9.js
└── login_e31e214b.css
如果按照上节的思路,可能需要为每个单页应用配置一段如下代码:
new WebPlugin({
template: './template.html', // HTML 模版文件所在的文件路径
filename: 'login.html' // 输出的 HTML 的文件名称
})
并且把页面对应的入口加入到 enrty
配置项中,就像这样:
entry: {
index: './pages/index/index.js',// 页面 index.html 的入口文件
login: './pages/login/index.js',// 页面 login.html 的入口文件
}
当有新页面加入时就需要修改 Webpack 配置文件,新插入一段以上代码,这会导致构建代码难以维护而且易错。
解决方案
上一节中的 web-webpack-plugin 插件也内置了解决这个问题的方法,上一节中只使用了它的 WebPlugin
, 这节将使用它的 AutoWebPlugin
来解决以上问题,使用方法非常简单,下面来教你具体如何使用。
项目源码目录结构如下:
├── pages
│ ├── index
│ │ ├── index.css // 该页面单独需要的 CSS 样式
│ │ └── index.js // 该页面的入口文件
│ └── login
│ ├── index.css
│ └── index.js
├── common.css // 所有页面都需要的公共 CSS 样式
├── google_analytics.js
├── template.html
└── webpack.config.js
从目录结构中可以看成出下几点要求:
- 所有单页应用的代码都需要放到一个目录下,例如都放在 pages 目录下;
- 一个单页应用一个单独的文件夹,例如最后生成的
index.html
相关的代码都在index
目录下,login.html
同理; - 每个单页应用的目录下都有一个
index.js
文件作为入口执行文件。
虽然
AutoWebPlugin
强制性的规定了项目部分的目录结构,但从实战经验来看这是一种优雅的目录规范,合理的拆分了代码,又能让新人快速的看懂项目结构,也方便日后的维护。
Webpack 配置文件修改如下:
const { AutoWebPlugin } = require('web-webpack-plugin');
// 使用本文的主角 AutoWebPlugin,自动寻找 pages 目录下的所有目录,把每一个目录看成一个单页应用
const autoWebPlugin = new AutoWebPlugin('pages', {
template: './template.html', // HTML 模版文件所在的文件路径
postEntrys: ['./common.css'],// 所有页面都依赖这份通用的 CSS 样式文件
// 提取出所有页面公共的代码
commonsChunk: {
name: 'common',// 提取出公共代码 Chunk 的名称
},
});
module.exports = {
// AutoWebPlugin 会为寻找到的所有单页应用,生成对应的入口配置,
// autoWebPlugin.entry 方法可以获取到所有由 autoWebPlugin 生成的入口配置
entry: autoWebPlugin.entry({
// 这里可以加入你额外需要的 Chunk 入口
}),
plugins: [
autoWebPlugin,
],
};
以上配置文件为了重点展示出本节侧重修改的部分,省略了部分和上一节一致的代码,完整代码可以参照上一节或者下载本项目完整代码。
AutoWebPlugin
会找出 pages
目录下的2个文件夹 index
和 login
,把这两个文件夹看成两个单页应用。 并且分别为每个单页应用生成一个 Chunk 配置和 WebPlugin
配置。 每个单页应用的 Chunk 名称就等于文件夹的名称,也就是说 autoWebPlugin.entry()
方法返回的内容其实是:
{
"index":["./pages/index/index.js","./common.css"],
"login":["./pages/login/index.js","./common.css"]
}
但这些事情 AutoWebPlugin
都会自动为你完成,你不用操心,明白大致原理即可。
template.html
模版文件如下:
<html>
<head>
<meta charset="UTF-8">
<!--在这注入该页面所依赖但没有手动导入的 CSS-->
<!--STYLE-->
<!--注入 google_analytics 中的 JS 代码-->
<script src="./google_analytics.js?_inline"></script>
<!--异步加载 Disqus 评论-->
<script src="https://dive-into-webpack.disqus.com/embed.js" async></script>
</head>
<body>
<div id="app"></div>
<!--在这注入该页面所依赖但没有手动导入的 JavaScript-->
<!--SCRIPT-->
<!--Disqus 评论容器-->
<div id="disqus_thread"></div>
</body>
</html>
注意到模版文件中出现了2个重要的新关键字 <!--STYLE-->
和 <!--SCRIPT-->
,它们是什么意思呢?
由于这个模版文件被当作项目中所有单页应用的模版,就不能再像上一节中直接写 Chunk 的名称去引入资源,因为需要被注入到当前页面的 Chunk 名称是不定的,每个单页应用都会有自己的名称。 <!--STYLE-->
和 <!--SCRIPT-->
的作用在于保证该页面所依赖的资源都会被注入到生成的 HTML 模版里去。
web-webpack-plugin 能分析出每个页面依赖哪些资源,例如对于 login.html
来说,插件可以确定该页面依赖以下资源:
- 所有页面都依赖的公共 CSS 代码
common.css
; - 所有页面都依赖的公共 JavaScrip 代码
common.js
; - 只有这个页面依赖的 CSS 代码
login.css
; - 只有这个页面依赖的 JavaScrip 代码
login.css
。
由于模版文件 template.html
里没有指出引入这些依赖资源的 HTML 语句,插件会自动将没有手动导入但页面依赖的资源按照不同类型注入到 <!--STYLE-->
和 <!--SCRIPT-->
所在的位置。
- CSS 类型的文件注入到
<!--STYLE-->
所在的位置,如果<!--STYLE-->
不存在就注入到 HTML HEAD 标签的最后; - JavaScrip 类型的文件注入到
<!--SCRIPT-->
所在的位置,如果<!--SCRIPT-->
不存在就注入到 HTML BODY 标签的最后。
如果后续有新的页面需要开发,只需要在 pages
目录下新建一个目录,目录名称取为输出 HTML 文件的名称,目录下放这个页面相关的代码即可,无需改动构建代码。
由于 AutoWebPlugin
是间接的通过上一节提到的 WebPlugin
实现的,WebPlugin
支持的功能 AutoWebPlugin
都支持。
AutoWebPlugin
插件还支持一些其它更高级的用法,详情可以访问该项目主页阅读文档。
本实例提供项目完整代码