vue3多页面改造

追旅
552 阅读4分钟

前言

之前都在开发pc，由于项目较为混乱做了大量的优化改造工作，我以为事情就这么简单，直到我接触h5页面，人都傻了，几十个项目甚至大屏都放到一个项目里，资源也没有做任何隔离，甚至还有egg在使用，项目都起不来，适配规范混乱，总之不堪入目，所以在新项目第二个迭代开始我就开始了移动端项目的改造

为什么使用多页面

任何项目的开端就是技术选型，技术选型会影响之后的开发、测试、部署等，而技术选型又是重中之重，至于项目的走向、扩展程度、维护度也都跟此节点息息相关。说多页面之前先了解一下单页面

  • 单页面

单页面其实是对单个应用来说的，编译后的资源只有一个html入口，所以和服务器的沟通其实就在初次拉取资源的时候，后续可以做缓存等很多优化手段，具备页面性能的提升友好、部署方便、占用服务资源少等优点

  • 微应用

当应用多了起来，项目开始变重，但由于基础服务都是公用的，例：登录、权限等，所以为了更好的维护和管理，就会做微应用的拆分

  • 多页面

但若是项目出现很多应用，而他们之间并没有任何关系时，选择单页面一开始就是个错误，导致的后续问题是：

  1. 一个很小的页面部署时，会打包所有资源 & 批量部署
  2. 访问A页面时会加载毫不相关的B页面资源、脚本等
  3. 随着项目发展，整个项目臃肿，编译、部署速度随之下降
  4. 项目维护度开始变差，难以扩展，项目杂乱不堪，甚至出现多个不同技术版本

所以，没有一成不变的技术，项目不同技术选型便不同。

项目改造

为保障对原有项目的最小影响，此次改造在最小范围内进行改动（尽管有些看起来可能不合理，但对项目来说相对友好，对关联项目影响几乎没有）

目录结构

├── public                     html模板
│   └── index.html
├── src
│   ├── components             公共组件
│   ├── hooks                  公共hooks
│   ├── pages                  各应用
│   │   └── index              默认工程为报告页面
│   │       ├── apis           私有接口
│   │       ├── router         私有路由
│   │       └── main.js        私有页面入口，统一为main.js
│   ├── router                 公共路由
│   ├── store                  公共状态，项目暂未涉及
│   ├── styles                 公共样式
│   ├── utils                  公共方法
│   ├── views                  公共业务页面
│   ├── App.vue                公共入口
└── vue.config.js              公共配置

vue.config.js

先介绍配置的改动，其余配置不变，添加pages配置，动态匹配各个应用入口，入口文件统一为main.js，配置如下

const glob = require("glob");
const path = require("path");
const { defineConfig } = require("@vue/cli-service");

let modules = process.env.npm_config_module || "";

const getConfig = (key) => {
  return {
    entry: `src/pages/${key}/main.js`,
    template: `public/${key}.html`,
    filename: `${key}.html`,
    chunks: ["chunk-vendors", "chunk-common", `${key}`],
  };
};
const getPages = () => {
  const pages = {};
  modules = modules ? modules.split(",") : null;
  if (modules && modules.length) {
    // 本地，指定modules
    modules.forEach((item) => {
      pages[item] = getConfig(item);
    });
  } else {
    // 减少对运维影响，生产批量打包
    // 上述批量打包为妥协方案（实际对于生产环境也应该各应用各自打包，但需对部署进行改造，但对于项目的健康发展，部署应根据实际项目做相应的部署）
    const PATH_ENTRY = path.resolve(__dirname, "./src/pages/*/main.js");
    glob.sync(PATH_ENTRY).forEach((item) => {
      item = item.split("/");
      const key = item[item.length - 2];
      pages[key] = getConfig(key);
    });
  }
  return pages;
};

module.exports = defineConfig({
  pages: getPages(),
});

对pages介个配置做简单介绍

  • entry

工程入口文件（打包入口文件），统一为main.js

  • template

html模板，名称为模块名称，若在public文件下找不到该模块则默认取index.html

注：目前index.html下引入有uni

  • filename

打包后html名称

  • chunks

提取公共模块

命令

为提升本地速度，可以根据不同命令运行不同应用，命令同原按需编译命令，默认编译所有模块，添加module编译指定模块，代码参考上边vue.config.js

"start": "npm run serve",
"start:report": "npm run serve --module=index"

公共资源

  • components

保持不变，仍为公共组件

  • hooks

保持不变，仍为公共hooks

  • router

只保留公共路由数据，真实路由信息转义到各自应用中

  • store

公共store，目前尚未涉及，同router部分

  • utils

公共方法，除request.js其他不变

由于路由信息迁移到各自模块中去，当接口登录失效时调用的router为各自应用的router，故对此改造，使用时需注意

  • views

公用页面，如：404、无权限、重定向等页面

  • App.vue

作为通用入口，若不满足需求，到各自应用下另外创建

各应用

pages为各应用业务开发区域，与原单页面开发文件结构相同，但有几点需要注意

  • 工程入口

必定存在main.js作为入口

  • 路由

history配置需根据实际项目配置默认路径，默认为process.env.BASE_URL，若nginx配置为/h5/test，则为process.env.BASE_URL + test

  • 接口

需传入router，使用如下：

// router
import router from "@/pages/index/router";

const instanceQuiet = getRequest(router);

public

每个独立应用匹配对应的html文件，若匹配不到则默认以index.html为模板

部署

不同应用打包后入口不同，即对应html不同，所以nginx配置时需做对应配置，其余不变

结语

终！！！心累了！！！

avatar
文章
阅读
粉丝