关于低代码相关的理解

大纲

前端在开发活动过程中,前端开发流程老的方式就是设计出图=>前端开发页面=>对接接口调整页面交互逻辑=>测试完上线=>运营配置活动。
低代码重点是为了满足大部分日常活动的需求,运营可自主配置活动并上线,释放了相当一部分的开发人力。
不过,此时的方案仍然无法很好地服务大型直播活动场景,比如年度 S 级的直播活动,这类活动赛程多且持续时间长(可长达两周),页面和组件都包含多种状态,运营难以配置出大型直播活动的所有需求,故此阶段的大型活动仍然完全由开发编码实现,需要占用较多人力,但此类活动从数量上来看连 1% 都不到。鉴于我们已在日常活动中积累维护了相当多功能的低代码组件,如何复用已有的低代码组件来更快实现更多活动玩法就成了一个值得研究的问题。此外,大型活动从筹备到结束,时间长达数月,而密集开发阶段可能只占其中的一个月,密集开发结束后的长尾需求又该如何优化提效?需要探索前端在活动场景的低代码相关经验,以及最终稳定的开发模式。

独占式文件锁定3

这是一个非常硬核的系统级需求。你想要的是 强制性锁定(Mandatory Locking)

在 Node.js/Electron 的标准 fs 模块中,fs.open 打开的文件默认通常是允许“共享读写”的,这意味着虽然你打开了文件,外部程序(如记事本)可能仍然能读取甚至修改它(取决于 OS 及其共享标志)。

要实现“只能在你的 IDE 操作,外部完全无法重命名、删除、修改”,你需要绕过 Node.js 的 fs,直接调用操作系统的原生 API(Windows API)。

兼容一键切换是否锁定文件夹

之前介绍了两种锁定文件的形式,

1、句柄占用
2、icacls 权限管理
最后我选择了icacls权限管理,因为它更加灵活,可以针对文件夹和文件分别进行权限控制。

问题,icacls管理 是可行的,但是我担心后面又不想要权限管理了(这个取决于需求)
研究后发现改动点其实主要在文件和文件夹的修改 保存 删除 重命名 的方式不一样。
icacls 都是先解锁 然后操作 然后上锁
正常模式就是没有解锁上锁的过程
目前就是要兼容这两种 一键切换。

当前网速较慢或者你使用的浏览器不支持博客特定功能,请尝试刷新或换用Chrome、Firefox等现代浏览器