对于表格，列表末尾数据可删除时，存在删除后刷新数据，当前分页下无数据的问题。 这里需要对几种状态条件做处理:

function defaultCheck (source, target) { return source === target } const MAX_RANGE = 10000 /** * 数组数据比对 * @summary * 比较数组差异，筛选出: * 1.相同项 ( 未改变 ) * 2.旧的不同项 (已删除) * 3.新加入项 (新添加) * 用于多选数组数据比较 * 注意：限制了最大便利数 MAX_RANGE * @param {*} oldList 旧数据

当前需要开发弹窗拖拽移动功能，在通过mousemove计算坐标点位时，出现计算后点位始终与鼠标坐标存在一定比例差异，并且距离初始未知越远差距越大。

当UI库弹窗无法满足自定义需求时，需要我们自己开发简单的弹窗组件。弹窗组件与普通业务组件开发没有太大区别，重点在多弹窗之间的关系控制。例如： 弹窗1，弹窗2 由于触发时机不同，需要不同的层叠关系，后触发的始终在最前端，点击弹窗头改变层叠关系。 单一弹窗多处调用等。这里封装基础的管理钩子，简化这些问题的处理。

组件初始加载时, 通过外部接口拉取需要设置的表格项数据. 通过表格实例方法toggleRowSelection 设置已选项无效.

记录pinia核心源码阅读笔记，这里跳过hmr(热更新), mapHelpers(class 工具)等工具源码。 剔除的部分vue2.0兼容代码。 当前pinia版本2.0.13

上篇[axios 二次封装-拦截器队列, 这篇是基于拦截器队列实现的状态处理拦截器, 某些情况下我们需要针对不同的响应状态码，执行不同的处理函数。例如：

查看axios的源码，会发现拦截器是由简单数组实现，挂载use eject 方法。拦截器注册的Id实际就是数组的编号，实现的核心在request调用前的拦截器队列编排上。满足平常开发，如果想做扩展就有些限制，所以这里希望通过提供一个自定义的拦截器中间层。提供些扩展功能。

aysnc-validator是对async-validate的二次封装库，用于对象值的校验。

在linux中文件的权限可以通过类似 0777,0666 的形式表示，包括许多语言操作文件时也需要传入这样的权限标识。这里记录对于权限标识的理解。

将错误处理放在所有处理之后，这种模式对于需要处理全局错误时，会产生大量模板代码，且如果需要处理的错误类型比较多的话。处理函数体积将变得比较臃肿，一些不相关的逻辑混杂在一起

最近在做axios的二次封装，在配置拦截器时。发现实际的调用流程与预想的不太一致。所以去看了看axios拦截器部分的源码，大概了解拦截器的实现。 一下是对拦截器实现的一些理解。

状态模式 状态模式将状态的切换交由具体的处理节点做判断， 容器只提供执行上下文 类模式实现 /** * 处理节点类 */ abstract class State{ state: string next: State constructor(state: string, next?: State){ this.state = state this.next = next || this } // 状态切换方法，交由具体的子类实现 abstract chang

VueTypes vue props 类型定义工具， 使用链式调用的方式定义vue props

平常开发时经常需要做数据结构的转换映射, 例如 时间区间数据， 后台返回的是两个字段的对象 { startTime, endTime } , UI组件需要数组类型[ startTime, endTime ]。 在结构转换中，对象字段遍历的频率是比较高的。

Tailwind CSS 是一个功能类优先的 CSS 框架，它集成了诸如 flex, pt-4, text-center 和 rotate-90 这样的的类，它们能直接在脚本标记语言中组合起来，构建出任何设计

Web Components 是一套不同的技术，允许您创建可重用的定制元素（它们的功能封装在您的代码之外）并且在您的web应用中使用它们。

通过组件模拟条件分支 例子 <Branch> // 分支容器 <If status={false}> // if if </If> <ElseIf status={false}> // else if else </ElseIf> <br /> // 支持嵌套 <Else> // else

除了通过独立配置每一图表数据， echart 提供 dataset 集中管理实例内的数据集合。

入门学习electron时了解到，渲染进程与主进程存在一对多的关系， 渲染进程与主进程需要通过ipc或remote进行通信。因为ipc的使用类似websocket, 发送和监听分离到两个独立的接口且渲染进程与主进程的接口存在不小的差异。 所以使用时存在几个比较麻烦的点: 1. 对于类似http的请求模式，接收和发送逻辑存在割裂。 2. 手动指定各个窗口发送比较繁琐。 所以打算尝试通过ipc封装一个无用的通信轮子。 简单例子 // 渲染端 const renderSocket = new Rende