前言

最近发现我们的项目构建速度越来越缓慢的，不得已，还是得稍微解决一下构建问题的。

首先我们的项目本身对浏览器兼容性要求不高，所以构建是可以省略很多内容的，首先推了一下另外一个小伙伴把错误的 .browserslistrc 改了一下。

一个常见的错误就是声明 last 2 version:

> 1%
last 2 versions

事实上你认为 last 2 version 是指浏览器最新的 2 个版本，这个 2 个版本是包含所有浏览器的。换而言之 ie 的两个版本（IE10 & IE11）都会被囊括的。

所以你需要新增两个“补充条款” ———

not dead
not ie 11

这样就把已经上路的浏览器和还算没上路 IE11 送走了。

下面就是调整一下构建。

序

在过去的几年里面，我陆陆续续的更换了很多次编辑器，其实最早我用的一直是印象笔记。通过印象笔记我积攒了很多的笔记和知识记录。但是随着国内印象笔记的逐渐发展，他变得越来越不好用了，甚至出现了广告，虽然是他们自己家的，但是这种行为让我越发的感受到不舒服。

受迫于早些年我买了10年的会员，这个时候就暂且忍住了，直到前几年他推出了越来越过分的会员制度和策略，一遍又一遍的刷新了下限（和百度网盘那样）。

于是忍无可忍的我终于决定彻底从他那边出走，寻找一个更好的知识管理软件，如果是 markdown 的那就更好了。

在一段时间的搜索后，终于发现了一个更好玩的东西 —— obsidian。

10月10号瞅见 volar 更新了，今天早上过来就把 volar 升级了，从官网上来说，volar 实现了一个与 vue 框架无关的外置 ts server 用来给 vue 以外的语言实现语言服务器，比如 svelte。

当然这不是我比较关心的内容，从 release 的信息看主要提升在于性能，目前实际测试下来速度提升还是非常明显的。

之前 vue 文件的提示大约需要 100-500 毫秒的事件才能显示，现在 打开文件，输入以后几乎没有延迟就可以获得补全提示了。

此外就是项目的 vue-tsc 检测速度也大幅度提升（虽然我看 vue-tsc 代码也没改动），原先检测整个项目需要花费约 22秒的时间，现在在6秒内就可以出结果了。

当然现在 volar 对于项目内的 vue-tsc 版本也会进行检查，如果出现下图的内容，直接升级一下 vue-tsc 即可。

原文地址： https://blog.vuejs.org/posts/volar-1.0.html

之前我介绍了一下 lunar-vim，lunar-vim 诚然是一个不错的选择，但是实际上在 vscode 中直接开启 vim 已经能有不错的体验的了，这里只需要稍稍做一下配置的修改即可。

序

随着 vue2.7 的正式发布，我们终于也开始升级 vue2.7 了。本文算是对 vue 升级方案做一个简单的记录。

概述

vue2.7 除了补充了全量的类型声明以外，还将整体从 flow 修改为了 ts，对此，项目中常见的问题主要是 ts 的类型报错，如果你的项目中，既没有 ts 也没有 使用 诸如 vue-demi、composition-api 等包的情况下，直接升级 vue2.7 对于你的使用来说是没有差异的。

很不凑巧的是，我们既使用了 vue-demi 又使用了 composition-api ，还很不凑巧的有 tsx 和 ts。

前言

写着这么一个组件的原因也比较简单，因为现在在做的低代码编辑器需要可以进行事件的控制，而事实上我们的低代码平台的实现上主要还是比较偏向指令式的换而言之通常是这么个逻辑执行的：

执行 xxx 操作 -> 打开弹窗 -> 填写表单 -> 关闭弹窗  

那么自然而然的，我们就可以想到实现这种运行方式的编辑器，必然是一个流程图编辑器，那么在流程图编辑器获得 json 数据以后要怎么执行便成了问题。

在第一版我们不需要实现非常复杂的管理，可以简单的直接使用递归的方式直观的实现。

前言

这里是 unity 学习过程的笔记入口，相关的 unity 文章将会链接到这边

序言

这篇文章在 notion 那边放了很久了，现在拉过来这边重新复刻一遍，其实只是为了试试博客的 mathjax 没有正常工作（）

记得那个时候写这篇文章的时候，大家在出面试题，这里就提到了青蛙跳格子的经典问题（就是 斐波那契数列 求 n 项的变种），所以顺手就整理了一篇文章出来。

前言

今天把整个博客都整理了一下主要是把 webpack3 升级到了 webpack5，可能是年纪大了，一些花里胡哨的东西都不太喜欢了。就把页面上以前一些花里胡哨的东西都移除了，留下了一个干干净净的，纯粹的文章页面。

在升级的过程中，发现了 webpack5 和 webpack3 & webpack4 比较大的一个差异点 —— 资源处理。

表单验证

说起表单验证，这可是一个经久不衰的话题了，不论是新型的 low code 方案还是老旧的手写方式。

表单验证已经在过去长久的实践里面获得通用的认识，所以大体上，绝大多数的表单验证，在观感上、体验上基本都是一致的。

通常而言，我们常见的都可以发现大致有这么几种表单验证方式：

• 基于 JSON schema 的
• 基于 js 配置的
• 基于 class 的

而我们目前使用的 ant-design-vue（1.7.8） 的表单验证器，至少在现阶段说不上好用，勉强算是灵活有效，适应面广泛。

而 ant-design-vue 的表单验证基本是基于 async-validator 的这带来的比较大的问题就是写起来其实蛮繁琐的。

随手举个官网的例子：

ruleForm: {
    pass: '',
    checkPass: '',
    age: '',
},
rules: {
    pass: [{ validator: validatePass, trigger: 'change' }],
    checkPass: [{ validator: validatePass2, trigger: 'change' }],
    age: [{ validator: checkAge, trigger: 'change' }],
},

最大的特点就是 rules 的声明与 form 分离，且极其不直观。

当然这也是 js 配置方式的一贯特点，很灵活，没有什么太大的劣势。

那么对于我来说，我觉得代码这个东西，主要还是人阅读的，从这个基本点出发，我还是希望稍稍的改善一下阅读体验，但是呢，并不想太过改动原本的验证逻辑。

那么实际上用 class 方式的验证就可以做到。