该插件仅用于本地开发, 不会影响生产打包.
该插件仅适用于 umi4.
在开发一些大型项目时, 由于页面较多, 热更新的效率比较慢, 往往一个改动需大十几秒的时间.
有两个主要的原因会影响热更新的速度:
-
当使用约定式路由时, 每次热更新时 umi 都会遍历 src 文件夹来生成一份路由表. 当文件夹中的文件很多时, 每次遍历都会花费好几秒的时间.
-
项目越大路由越多, webpack 需要编译的时间肯定越多, 热更新时间自然变长.
本插件会从这两方面来着手.
对于第 1 点, umi 在开发模式下每次监听到文件变化后都会执行一个 getRoutes 方法. 在这个方法里如果用户使用的约定式路由则会执行一个 getConventionRoutes 方法, 而如果用户使用的是配置式路由则会执行 getConfigRoutes 方法. 目测 getConventionRoutes 方法由于需要访问文件系统, 它的执行效率肯定要比 getConfigRoutes 这种纯粹的 js 方法要低很多1. umi 之所以每次都要走这个方法, 是希望路由表能得到最及时的更新. 但是我们平时在开发时其实大部分的时间都是在开发页面, 而改动路由的概率并不大, 真的改动了路由, 重启一下服务就可以了.
// 代码有简化, 仅用于示意.
export function getRoutes(opts) {
let routes;
if (opts.api.config.routes) {
routes = getConfigRoutes(...)
} else {
routes = getConventionRoutes(...)
}
return routes;
}所以我的想法很简单, 在某一个时机根据约定式路由生成一份配置式路由, 然后把它赋给 api.config.routes. 那么每次 umi 监听到文件变化后就只会走 getConfigRoutes 方法了, 而不会走 getConventionRoutes 方法了. 相当于在配置文件中给它加上了 routes 配置.
那在哪个时机做这件事呢? 我们知道 umi 在启动时会经历几个阶段: resolveConfig -> collectAppData -> onCheck ...
在 collectAppData 阶段执行完成后, umi 会把路由信息存进 api.appData.routes.
当然这个 routes 跟配置表中的 routes 并不是同一个东西, 需要经过一定的转化, 然后把转化后的值赋给配置表. 插件就在 modifyAppData 这个回调里工作.
对于第 2 点, 当我们在开发项目的时候其实并不需要全部的路由, 大部分的时间往往只会专注在某几个路由上, 那么项目中的其它路由就可以忽略, 从而减少编译的时间.
通过指定那几个路由, 插件会自动忽略掉其它的路由, 同时又不会影响生产的打包.
做到了以上两点后, 热更新速度大约可以快一倍 (约定式路由模式下)2.
- 安装插件
yarn add route-picker-umi-plugin --dev
- 在配置文件中注册插件. (
.umi.rc或者config/config.ts等)
// umi 配置文件
export default defineConfig({
plugins: ["route-picker-umi-plugin"],
});- 指定你想要保留的路由
// umi 配置文件
export default defineConfig({
plugins: ["route-picker-umi-plugin"],
routePicker: ['your-route']
});- routePicker 里指定的路由并不需要完全匹配, 部分匹配就可以生效. 比如你可以指定 'user', 那么像 'user/login', 'user/add' 等一系列路由都将被保留.
- routePicker 若为空或者是空数组, 则所有路由都会被保留.
- 即使你并不想要过滤掉任何路由, 这个插件仍然值得开启, 因为对于约定式路由的热更新, 插件还是能够为你减少很多的时间. (上文的第一点)
本插件只适用于 umi4, 如果是 umi3 请使用 route-picker-umi3-plugin