既然你已经有了工程文件的结构数据(比如是从 project.config.json 读取出来的树形结构),现在的核心任务是:验证这些路径在磁盘上是否真的存在,并根据结果更新 UI。
这是一个典型的 “元数据” vs “物理数据” 的校验场景。
为了保证性能(避免成百上千次 IPC 通信),我们应该采用 “批量校验” 的策略。
READ MORE
div>
这是一个非常硬核且实用的需求。要实现类似 VS Code / Visual Studio 的工程文件资源管理器,我们需要打通 Electron 的 Main Process (Node.js fs 能力) 和 Renderer Process (Vue 组件交互)。
由于代码量较大,我将分为 后端 (IPC/Node) 和 前端 (Vue 组件) 两部分来构建。
READ MORE
div>
READ MORE
div>
前言
通过indexDb存储pinia的相关数据。传输的时候不用传输整个数据
核心思想转变:
之前的模式是 “数据跟随消息” (Push Data),现在的模式是 “消息通知,数据自取” (Signal & Pull)。
- 写入方:Store 变更 -> 写入 IndexedDB -> 发送 “数据已更新” 的信号(不带数据)。
- 接收方:收到信号 -> 从 IndexedDB 读取最新数据 -> 更新 Store。
- 初始化:新窗口启动 -> 请求初始化 -> 老窗口强制将内存数据刷入 IndexedDB -> 发送 “准备好了” -> 新窗口从 DB 读取。
这样做的好处是 BroadcastChannel 极其轻量,不再受数据大小限制,且数据持久化由 IndexedDB 承担。
READ MORE
div>
READ MORE
div>
1 | // src/main/index.ts |
READ MORE
div>