Vue开发

1. 前言 在Vue3开发过程中，每次创建新的页面都需要注册路由，需要在src/router.ts中新增页面的路径，并将URL路径映射到组件中，如下所示： import { createMemoryHistory, createRouter } from 'vue-router' import HomePageView from './HomePageView.vue' import DevListView from './DevListView.vue' const routes = [ { path: '/', component: HomePageView }, { path: '/DevListView', component: DevListView }, ] const router = createRouter({ history: createMemoryHistory(), routes, }) 虽然看起来工作量不大，但如果页面特别多，就会感到繁琐。即使是微小的改动，如组件名的修改，也需要在路由文件中反复确认，反复如此就会感到不便。为了简化这部分工作，我想到了一个解决方案，那就是开发一个Vue3菜单路由生成工具，只需填写组件的中文名称，根据树形结构生成一个与routes结构相同的数组，然后替换使用即可。但还是觉得不够好，随后想到既然自己能发现这个问题，别人可能早已有了应对方案。接着，我就发现了 unplugin-vue-router 插件。 2. 配置 2.1 安装 npm install -D unplugin-vue-router 2.2 vite.config.ts import VueRouter from 'unplugin-vue-router/vite' export default defineConfig({ plugins: [ VueRouter({ /* options */ }), // ⚠️ Vue must be placed after VueRouter() Vue(), ], }) 2....

前言 在项目开发过程中，计划将组态页面的渲染器集成到组件库，以 npm 包的形式供后续项目模板复用。如此一来，倘若组态页面渲染出现问题，便能简化修复与迭代工作。 遇到问题 采用本地引入方式开发完成后，切换至 npm 包方式使用，此时面包屑可正常显示，然而组态页面部分却呈现空白状态。 分析问题 既然面包屑显示正常，那就表明通过向组件传入 Router 对象进行相关操作并无问题，毕竟面包屑与组态页面共同构成了项目中的具体功能页面。不可能 Router 有问题，面包屑却还能正常显示。 推测组件打包生成 npm 包后，自身未携带 Vue 环境，致使 Vue 内置特殊元素 <component> 渲染失败，此前使用 Pinia 时就碰到过类似情况。 那么，该如何在组件里创建 Vue 环境呢？ 要是不使用 <component>，而改用渲染函数来实现会怎样呢？ markRaw 的作用是什么？ 利用渲染函数实现后，发现打包成 npm 包使用时依旧出现空白，这就说明并非 <component> 的问题，如此一来，问题范围便缩小到组态页面的数据源上了。 对比本地引用和 npm 包两种方式下的数据请求差异，发现使用 npm 包时，存在接口未发起请求的情况，进而定位到问题根源。 问题原因 由于该渲染器是在项目中使用，其请求的 baseURL 是通过 window.location.origin 获取的。在本地引入使用时，本地开发服务器地址为 http://localhost:3000/，并且在 Vue 项目的 vite.config.ts 中已做代理，所以请求正常。但当把渲染器代码移至组件库并以 npm 包方式使用时，它自行获取的请求地址仍是 http://localhost:3000/，并未经过代理处理，致使请求资源的接口异常，最终造成页面空白。 const baseURL = import.meta.env.DEV ? "http://192.168.50.20" : window.location.origin 总结 解决 Bug 的思路仍有待提升，自己还是过于急于求成了。刚察觉到问题的一点苗头，就贸然行事、妄下结论，实在有些武断。一开始认定是 <component> 的问题，就应当采用排除法，不该如此笃定。实际上，只需用简单示例测试一下，便能排除该选项，也不至于耗费大量精力深入研究如何在组件里创建 Vue 环境？如何用渲染函数实现组件？平白浪费了许多时间。...

1. 背景 当前的后台管理系统主要负责云平台和云服务器的管理，并且是以Web应用的形式在使用。但是，当出现服务器紧急情况或需要进行平台注册审核时，如果这些任务发生在非工作时间，例如在通勤路上，我们就无法使用PC浏览器进行访问和操作，这显然是不方便的。另外，由于后台管理系统仅供内部人员使用，我们只需要它能满足基本的查看和配置需求，对于便利性和美观性并没有太高要求。因此，将Web端的所有功能移植到手机端并开发一个App，显然很不划算。毕竟，每当Web端功能迭代时，App端也需要同步更新，这意味着同一功能需要实现两次，所以，开发App的方案就不考虑了。 2. 方案 2.1 方案一：使用手机Edge、Firefox浏览器访问使用【推荐】 使用手机通过Edge或Firefox浏览器访问时，设置为“查看桌面网站”（Firefox中称为桌面版网站开关），即可浏览平台的完整布局，并通过手势放大和缩小来居中展示所需内容，操作便捷。 可将后台管理系统的管理平台添加到手机主屏幕，实现快速访问。 以TDesign页面模板演示效果。 2.2 方案二：当前页面 + 全屏 创建一个专为手机端使用的手机端菜单，仅显示关注页面，手机端访问时读取该菜单显示。 利用@media媒体查询调整各页面布局，例如筛选条件等，以避免布局错乱。 默认情况下，只能在手机横屏模式下使用，提供一个全屏按钮，点击后将当前页面全屏化，以争取更多展示空间。 2.3 方案三：远程软件控制电脑访问使用 使用远程软件（如向日葵）访问电脑，然后在手机端通过手势放大和缩小进行操作。效果与方案一相似，但存在以下不足： 输入时需要手动打开键盘。 页面有滚动条时操作繁琐。 连接可能不稳定，画质不佳。 3. 结论 方案一无需额外开发成本，只需在指定手机浏览器上使用即可。 方案二需要额外开发，且最终呈现效果可能不如方案一。 方案三存在上述提到的缺点。 综合考虑，推荐采用方案一。

1. 背景 公司有部门使用VuePress 1.0搭建平台的帮助文档，前期文档不是很多，所以没有暴露出特别明显的问题。但随着文档的逐步迭代和内容的增多，出现了大量的并发请求，总共有218个请求，导致服务器带宽耗尽、响应速度下降，进而影响了文档的使用。 2. 问题分析 VuePress 1.0是基于Vue 2和webpack实现的，其模块化方式使用的是CommonJS。这意味着，当项目打包部署在服务器并进行访问时，需要将源码全部加载完成后才能进行渲染，即同步加载。随着项目持续迭代，内容增多，性能问题逐渐显现。 3. 解决方案 考虑到向服务器发起了200多个请求，但查看那些.js文件，整个js文件夹大小才10.3MB，是否可以将10.3MB分为10个.js文件，减少请求至10次呢？ 3.1 方案一：替换成showDoc 使用showDoc在线文档系统，相比vuepress基于vue.js的静态站点生成器，除了操作便利，对于解决并发请求200次这个问题，还是有帮助的，毕竟showDoc初始化的时候，是从服务器获取文档目录，再通过文档ID，去请求文档详情，通常来说，不会有那么多文档目录，不太可能出现并发请求200次这个问题，只是将vuepress迁移至showDoc，花费的成本很高，文档格式需要调整，图片需要上传，想想这个工作量就头大，再者，作为平台的帮助文档，本身带有宣传的作用，很难醒目地在showDoc中体现平台的公司名和Logo，所以这个方案不推荐。 3.2 方案二：研究webpack如何合并打包 如果请求过多是因为文件太分散导致的，那么，能够在当前基础上，也就是webpack里，找到，当打包时，将各个文件合并，减少请求次数呢？ VuePress 1.0 支持通过 webpack-chain 链式操作来修改内部的 webpack 配置，如下所示： module.exports = { chainWebpack (config, isServer) { // config 是一个 ChainableConfig 的实例 } } 那在 webpack 中，如何对打包的体积、文件等进行处理呢？在 webpack 官方文档中，有推荐使用 SplitChunksPlugin 插件，是为了代码分割，减少包的体积，然后优化加载效率，感觉和自己的初衷背道而驰，最终没达到自己想要的效果。还有就是研究了下 ModuleConcatenationPlugin 插件，其作用是将所有模块的作用域“提升”或合并到一个闭包中，从而使得代码在浏览器中执行速度更快。但是因为要在使用 webpack-chain 去调研 webpack 的配置，尝试使用后也没达到预期，加上再花精力投入到 VuePress 1.0 和 webpack-chain 感觉有点不值。所以，就再想想其他方案。 3.3 方案三：替换成VitePress【推荐】 说到减少并发请求次数，实际上，Vite就在做这样的工作。Vite采用的JavaScript模块化方式是ESM（ECMAScript Modules）。与CommonJS相比，ESM支持按需加载，并且是异步执行的，不会阻塞浏览器的其他事件处理。这意味着在首次加载时，我们无需加载所有资源，仅需加载首页所需的资源即可。这样就能减少了并发请求次数，解决当前遇到的问题。 而VitePress，正是基于Vue 3和Vite构建的。 5. 方案验证 以下是两个文档框架的对比，内容基本为空，可忽略不计。可以看到VuePress 1.0初始化请求的就有26个请求，大部分都是.js文件，而VitePress 1.0只有9个请求，.js文件的请求才4个。 5.1 VuePress 1....

前言 因为之前只是用Vue来开发IaaS平台项目，其使用场景通常都是PC，所以没怎么涉及到Web响应式设计开发相关知识。最近项目刚好是应用在PC和平板，甚至是手机上的，所以就需要考虑响应式的问题。 1. 技术选型 Web响应式开发，主要是基于CSS里@media媒体查询实现，允许不同视图尺寸使用不同的布局。 1.1 方案一：Vue 3 + Vite + Bootstrap5 1.1.1 优点 容易上手：只要对 HTML 和 CSS 有基本了解的人都可以很快速的使用 Bootstrap。 响应式设计：Bootstrap 可以根据不同平台（手机、平板电脑和台式机）进行调整。 移动优先：在 Bootstrap 中，自适应移动端是框架的核心部分。 浏览器兼容性：Bootstrap5 兼容所有主流浏览器（Chrome、Firefox、Edge、Safari 和 Opera）。 如果您需要支持 IE11 及以下版本，请使用 Bootstrap4 或 Bootstrap3。 github 星数 164k Bootstrap5 效果演示：https://www.bootstrap-admin.top/ 1.1.2 缺点 没办法使用我们积累的vue next组件库 Bootstrap5 需要学习成本，但不会很难 相对紧急的项目，通常不应该引入新技术去开发实现，而是以快速交付为主。 1.2 方案二：Vue 3 + Vite + Element Plus + @media 1.2.1 优点 基于前端现有技术积累，可快速开发项目功能 1.2.2 缺点 前端封装组件库，并没考虑过响应式设计，潜在未知样式问题，如开发此项目，各组件需考虑各平台（电脑、平板、手机）屏幕适配的同时，还要考虑已引用该库开发的项目兼容性问题。 @media媒体查询需每个页面、每个平台去适配（Bootstrap5做的事情），工作量相对较大，因无更多平台设备去验证，潜在未知的样式问题。 1.3 结论 简单来说，可以理解为方案一Bootstrap5帮我们处理好了屏幕适配的问题，我们只需要关注功能开发即可，方案二则是功能也要开发，样式也要关注。长远来看，倾向于方案一开发。 2. 快速搭建 Bootstrap5官方文档有提供Vite基于开发的指南《Bootstrap & Vite》，我们虽然是基于Vue3开发的，但是相关配置基本都一样的，只是有一点点差异而已。...