前言最近在开发后台管理系统时，我遇到了一个常见的需求：在表格的操作列中，根据数据状态动态显示不同的操作按钮。为了让按钮之间排列整齐并带有分隔符，我使用了 Element Plus 的 el-space 组件。代码如下：<el-space size="16" spacer="|"> <el-button type="primary" text> 修改 </el-button> <el-button v-if="isRecycle" type="succ...
前言在前端开发中，为了确保一致和良好的用户体验，我们通常需要处理不同浏览器对 HTML、CSS 和 JavaScript 的支持差异。在 Vite 生态中，我们通常使用 .browserslistrc 文件来统一管理目标浏览器范围。像 postcss-preset-env 这样的工具会自动读取它来进行 CSS 降级。然而，一个常见痛点是 @vitejs/plugin-legacy 插件的 modernTargets 选项并不会自动读取该文件，需要我们手动配置。这就导致了同一个配置需要维护在两个地方：一份在 .browserslistrc 中给 PostCSS 使用，另一份在 vite.c...
前言在日常的 Vue 项目开发中，我们常常需要手动从 vue 或 vue-router 等库中导入 ref、computed、onMounted 等 API。这不仅是一项重复性的劳动，也打断了我们编写业务逻辑的思路。手动引入（之前）：import { computed, ref } from 'vue' const count = ref(0) const doubled = computed(() => count.value * 2)unplugin-auto-import 这款插件正是为了解决这个痛点而生。它能够自动为我们导入这些常用的 API，让我们专...
前言乘着年底没什么事，把axios和axios-retry的源码简单看了下，总结了下一些最佳实践。axios本身axios有个很便捷的使用方式，就是它既可以作为函数发起请求：axios()，也能通过它身上的属性，如：get、post、delete等来发起对应请求，也可以通过axios.request()来发起更加灵活配置请求，甚至还能通过axios.create()来创建自定义配置的请求实例。为什么它能有这么多请求方式？其实就是axios本身就是axios.request这个方法的bind返回值，当我们import引入这个axios的时候，引入的是request函数。import axi...
前言最近在写AI训练器的UI界面，有一个需求就是展示TOML配置，为此就需要用到代码高亮，我之前用过 highlight.js 和 PrismJS，但是在撰写VitePress项目配置时发现了一个新的代码高亮库：shiki。shiki可以省去维护css和html，并且原生就是ESM按需加载，支持多种主题等，已经满足了我对一个代码高亮的需求，为此我去尝试用了下这个，于是有了本篇文章。插件文档：Shiki语法高亮器github：shiki注意事项shiki是按需加载的，它的实现方式就是除了一个主体的js文件，在打包后会有非常多的不同代码语言的解析器脚本文件，但是不用担心，这些脚本文件只有在真...
前言一直很头疼axios的失败重试插件axios-retry会重复调用axios自定义的响应错误拦截器，而我们常常会在这个拦截器中编写一个用于弹出错误消息的弹窗，这就导致了一个问题：如果我们失败会重试3次，那么全部都失败的话就会触发4次响应错误拦截器，然后就会导致触发4次错误消息的弹窗，非常蛋疼。为此常常需要考虑怎么避免重复触发的问题，常见的一些做法比如通过自定义的拦截器接受的error对象上的config属性，添加一个计数器来处理，如果计数器大于等于3的话就可以触发消息弹窗。本来axios-retry插件本身就会在config上注入一个计数的属性和总次数，但是也没法用，实际测试中发现，...
前言项目全线使用vue3的时候，自然使用的是配套更加契合的vite打包工具，于是自然而然会用到很多新的语法，比如这两年开始普及的可选链语法，这个语法都已经纳入声呐的代码规范中了，但是vite自身打包的时候，并不会做过多的兼容处理。默认情况vite的兼容目标是支持原生ES模块，原生ESM动态导入和import.meta的浏览器，官方预设的兼容目标如下：es2020edge 88firefox 78chrome 87safari 14而我们的可选链正是es2020版本才有的，所以vite在打包后不会做任何兼容处理，这就导致了一些浏览器版本低一点的设备，打开网站就会出现白屏的情况。显然这么新的...
前言以前使用PostCSS做css兼容性处理，常常就是使用autoprefixer做个浏览器前缀处理就完事了，但是实际上如果真要实现所谓的兼容性处理，css甚至还需要做转换处理，类似于js的async...await的语法转换处理。autoprefixer只是自动添加浏览器前缀，而本次使用的postcss-preset-env除了自动添加浏览器前缀，并且会根据目标浏览器自动转换成兼容的格式，包含许多其他 CSS 提案的 polyfill。举个例子：:root { --main-color: #06c; } body { color: var(--main-color);...
前言最近在写新的项目，其中遇到一个问题，我的登录页和注册页相关的页面，他们的布局是相同的，所以理所当然的封装了一个layout组件，然后每个页面自己import引入它并使用，这么看其实没有问题。但是当我给layout增加了一个持久的动画的时候，切换页面由于组件会重新渲染，这就导致动画又重新开始了，显得整体非常突兀。于是不得不将layout组件提升到route-view路由视图的外层，然后又要考虑其他layout布局也要生效，于是就有了仿nuxt的动态布局的需求。我希望在路由的meta配上一个layout属性，然后通过这个属性指定对应的布局组件。[hide]代码注意事项首先不能直接从rou...
前言当我们访问一些需要登录才能访问的页面，通过路由守卫我们会被重定向到登录页，同时会在链接参数里携带一个redirect字段，表示登录完成后跳转到redirect的路由。单独考虑这个问题，我们只需要在登录页处理这个问题就行了，但是随着业务的变化，有时候不一定只在登录页使用，这个重定向的功能可以在多处使用。总不能在每个要用到重定向的地方加if判断是否存在redirect字段吧。为此我封装了一个专门处理重定向的hooks：useRedirect.ts代码[hide]// useRedirect.ts import type { RouteLocationRaw } from "vu...
前言之前的vite很多文章一直推荐使用的是rollup-plugin-visualizer插件，但是这个插件真的一点都不好用，和webpack的体积分析差太多了。这次新项目中也需要用到体积分析，需要我找了很久，找到一个新的插件，基本上可以和webpack的体积分析差不多体验了。插件：vite-bundle-analyzer效果图：相比较之前的还是挺好用的。教程先安装依赖：pnpm i vite-bundle-analyzer -D然后去vite.config.ts中配置：import { defineConfig } from "vite"; import { ana...
前言一般情况下确实用不到这种极端处理方案，因为有名的插件依赖，基本上能碰到的bug情况是非常少见的。这篇文章解决的问题是：将 node_modules 中的模块自己修改后，又不想影响全局引入方式，或者说不方便去修改该模块的引入的时候使用的。教程中使用的是pnpm方式，如果你使用npm或者yarn，原理是一样的，可以参考完再自己去看对应的命令使用方式，大差不差的。[hide]教程假设我们已经将模块自己改好并打包好了，此时我们一般会得到一个dist目录，这个是模块打包后的产物，假设这个模块在node_modules中的文件夹夹名字是test，那么你就需要将dist放置在自己新创建的test目...
前言最近网络不太行，发现pnpm在下载一些库的时候经常卡住不动了，我记得推崇pnpm的时候，大伙都说pnpm不需要换源下载也很快，显然没有理想中那么好，无奈只能换源解决问题了。教程换淘宝源：pnpm config set registry https://registry.npmmirror.com 还原：pnpm config set registry https://registry.npmjs.org查看当前使用的源：pnpm get registry pnpm好像目前没看到有什么库能交互式操作切换。新方案我最近安装pnpm都是通过npm来安装的：npm i pnpm -g然后我发...
前言最近发现这个很有意思的配置，可以让项目中强制使用指定的包管理器，其他人瞎鸡儿用的话就会报错阻止，这个配置其实在pnpm的官方文档里就有，只是一直都没发现。这里贴一下出处：Only allow pnpm下面开始教程。教程在开始之前我们需要了解一下，npm在安装包的时候其实是有一些预设的生命周期脚本的，当然这些脚本其实就是package.json中的scripts定义的命令，官方预设了一些名字，当你添加对应的脚本名字和内容的时候，npm会在install的生命周期中去运行对应时机的脚本命令。生命周期文档：npm-install示例：{ "scripts": {...
前言最近发现动态去拼接资源路径还是挺常用的，于是把我之前封装的hooks单独分享出来。教程useAssets.tsexport function useAssets() { /** 前缀补路径斜杠 */ // eslint-disable-next-line @typescript-eslint/no-unused-vars function addPrefixSlash(path: string) { return path.startsWith("/") ? path : `/${path}`; } /** ...
前言这段时间对接了下web版的谷歌登录，总体来说坑非常多，即便到现在，我都感觉这个教程都只能算是一个应急处理方案，并不完美，缺点如下：文档稀少，官方提供的教程自由度很差ui不可控，前端无法自定义触发按钮不多说，开搞！教程官方文档和流程官方文档：web谷歌登录流程：我们需要先去将需要web登录的域名去向谷歌申请一个客户端id，用于在客户端登录处理。申请地址：开发者后台创建凭据 --- 选择OAuth 客户端ID --- 应用类型选择 web应用 --- 自己填写一个名称已获授权的 JavaScript 来源这个选项意思就是你允许使用这个客户端id对应的网站域名，添加对应的网站地址，个人测试...
前言在pinia中使用setup语法是非常舒服的一件事情，但是也会有一些坑点，其中就是当我们使用store.$reset()进行重置的时候会发生报错：Store "xxxx" is built using the setup syntax and does not implement $reset()意思是$reset并没有实现，我们需要自己手动实现这个。教程解决办法我是从stackoverflow看到的，这里放出出处：《Pinia: $reset alternative when using setup syntax》我们需要创建一个插件去实现这个功能：stores...
前言pinia的作者最近在博客上放出了一篇pinia的使用文章：《My Top 5 Tips for using Pinia》，里面讲述了5个一般不怎么知道的使用技巧，但是由于讲的很浅，我这边自己理解了一下，做了一些解释，顺带记个笔记。不要创建无用的 getter这点我感同身受，在最初学习vuex的时候，前辈们总是会说，getter有缓存，性能会更好，于是，在大多数的教程中，我们总是能看到这种示例写法：export default Vuex.Store({ state: () => ({ counter: 0 }), getters: { ...
前言最近新学到一招，利用原生css实现首屏骨架，这样即可以省去在Home.vue组件中单独创建骨架，而且对html结构是0添加。先看看预览图：效果还是可以的。教程原理就是利用background-image的多重渐变实现骨架占位，配合background-size和background-position进行精准定位，如果你的骨架是大量重复内容，还可以配置background-repeat: repeat-y;进行y轴重复渲染，效果更佳。然后通过动画控制整体的透明度变化实现动效。再通过:empty伪类实现对#app是否渲染的判断。:empty会在对应的元素内部没有任何内容时生效。不多说，直...
前言多页面其实可以理解为多个独立的业务之间共享部分代码逻辑的实现。业务之间是相对独立的，只是小部分或者大部分的代码是可以共用的，常见的一个场景就是：改头换面形式的换肤。不同的皮肤之间毫无可复用组件代码的情况下，我们只能将通用的业务逻辑抽离成可复用的部分，简单点来说就是将数据与ui分离，数据是共用部分，ui是各自独立。最终衍生出的多页面结构大体如下：pages ├── pageA │ ├── App.vue │ ├── index.html │ ├── main.ts └── pageB ├── App.vue ├── index.html └── ma...
前言最近遇到这么一个头疼的需求，第三方提供了两份sdk，一个是针对安卓端使用的，一个是针对ios端使用的，但是他们都会在全局window上挂载同名属性对象，这就让我很难受了。<script src="/sdk/sdk.min.js"></script> <script src="/sdk/ios_sdk.min.js"></script>前端如果想要使用这个sdk就必须在head引入它，但是它又有两个脚本，后来的脚本又会覆盖上一个脚本在全局挂载的对象。理论上一个优秀的sdk不应该出现这种问题，它应该自...
最近评论