主要是技术上不一定方便实现自动化的检测。

可能到最后只能靠人去检查，但鲜有能分到这种事情上的人力资源。

重写 window.fetch 可太秀了，没见过的操作算是学习到了 😂

这是个历史遗留，目前来看用处不大了。效果基本等价于你写代码片段。

配置文件建议直接通过 saveData 存成 json 文件。

大的资源文件建议放到 /data/public （或者别的目录下），然后通过调用 putFile 等 API 来进行 IO 操作。

点进去添加一个 css 片段

需要频繁编辑比较长的嵌入块，推荐使用「文档流」插件，将嵌入块内容在文档流中打开后编辑起来会方便很多。

编辑器的对比度可以，方便阅读，这个好。

但是建议对不同层级的标题做一下区分。

我个人更加倾向颜色使用必要但克制，阅读体验清晰的风格。

你说的情况就相对复杂一些了。

我说的 「onunload 里面不要 saveData」 是表象。核心的关键其实是两点：

1. 思源会先启动插件再做同步
2. 同步数据完成后，思源有可能会 reload；reload 的过程中会调用 onunload 钩子

面对复杂一下的情况，就需要把握这两点进行具体分析了。

思源的群主要就是 1 2 3 群和折腾群了。

可以用这个 quicker 动作：

粘贴 GPT 数学公式 - by Frostime - 动作信息 - Quicker

我投一票赞成。

这属于 SQL 的问题。

限制只查询文档的话，就加上 type='d' 条件。

限制笔记本就用 box='笔记本ID' 做限制条件；子文档就用 path like '%文档ID/%' 做限制条件。

vite-svelte 模板提供了热重载，但是这个热重载本质是检测到文件发生变动就自动 window-reload。和无需刷新的热重载可能还有点差距，但其实日常使用也能用。

你如果不想要使用 node 环境开发，可以试一下‘开发 API’或者‘Run JS’。

这两个插件都把一些前端的 API 透传到了 globalThis 下面（RunJS 还透传了一些对 kernel api 的封装），这样直接在思源里面就可以调用一些给插件用的 api 了。

同意，比起评分，点赞会更好一些。前者会带来负面效应，后者则一般不会。

甚至可以放宽一点，允许用户重复点赞，从而和下载量做区分。

你们“为爱发电”开发软件的时间值钱，难道成千上万大众的筛选软件的时间成本就不值钱吗？

你这就是属于强行制造对立，混淆概念了。

「筛选软件的时间成本」和开发者开发软件没有直接关系，那是各种教程、分享、交流应该负责解决的事情。

只是说在这个案例里面，某人提出的针对「筛选软件的时间成本」的方案可能带来对开发者积极性的负面影响，这属于技术性问题，是方案设计的不够好的问题。比如某些插件被刷了低分、差评，那于作者而言是不是干脆下架插件，眼不见心不烦为好？——考虑到思源的社区规模比较小，目前不适合应用这种模式。（不过或许可以换成点赞这种只有正向反馈的模式，这个可能会好一点）。

总结一下就是：

• 「“为爱发电”开发软件的时间」和「成千上万大众的筛选软件的时间」这两者之间不存在内生性的矛盾，这个矛盾是被你人为拼接出来的。
• 你提出的核心矛盾是有问题的，所以你后面的就题发挥均没什么讨论的价值；任何字斟句酌都变成了无聊的对概念的辨析和对定义权的争夺。
• 如果你真的想要进行有意义的讨论，那也应该是技术性的，比如：如何在不影响开源作者的积极性的前提下构建一个有参考的评价、分享系统。

至于你强行把开源作者和普通用户对立，我只能这么说：

不一定需要复制出来，插件「集成编辑环境」是可以以 markdown 的格式修改笔记的内容的。

可以写个脚本定时调用内核的导出 API

https://github.com/siyuan-note/siyuan/blob/f7920fa853a2e5ad1ecb114d0bc54c039d5e5be5/kernel/api/export.go#L253

就我所知思源导出的 md 应该是相当纯了，你是遇到了什么特别问题了吗？

直接用肯定不行，架构不一样。

但是可以借鉴，比如 OB 插件比较多，可能有些奇思妙想的应用场景，可能迁移到思源中。

朋友，在线笔记和离线笔记的空间是不能放在一起算得。😂

在线笔记的空间算的是存储，没有什么特别的流量开支；而离线笔记的空间要算的是流量。

在目前的中国网络环境下，流量的费用是要显著高于存储的。

我理解你的不解，但是这个问题其实还挺复杂的。只能说选了离线笔记，在云端的成本就会有额外的“税率”😭 。

隐藏项目的那个需求，集市里面应该有已经实现好的插件，也许不用自己写 Observer。

目前只有日记是支持直接使用模板创建的，其他的都是先创建再插入模板

可能你遇到的场景比较复杂吧。

我之前也遇到过需要组件主动销毁自己并关闭 Dialog。不过我习惯的做法是向上传一个 close 事件，然后在外部的 js 里通过 component.$on('event') 监听这个事件，并引用 dialog 进行销毁。

你提到的是一个不同的思路，对我还是有些启发的，感谢分享 👍 。

感谢分享。关于内存泄漏，其实如果没有额外创建副作用，一般也不存在这个问题。毕竟 DOM 删掉了，引用计数器归零，自然会被回收。

出问题的主要就是那些创建了副作用，然后在 Unmount 生命周期钩子函数里做清理的。这种情况就必须 destroy 来手动触发 Unmount 生命周期的了。

我这两天又更新了一下模板，增加了一个 svelteDialog 方法，基本就是做了一个简单的包装，默认在回调中调用 destroy 销毁组件。

https://github.com/siyuan-note/plugin-sample-vite-svelte/blob/main/src/libs/dialog.ts

试一下这个？

div.protyle-wysiwyg[alias="whiteboard"] + .enhanceProtyleBottomContainer {
    display: none;
}

这个应该就是开玩笑的，没有恶意 😂

不过现在有个小瑕疵，展示的数据库块不但显示数据库标题，还显示该数据库各视图的名称，看起来不够简洁。

可以给块命名。目前插件的逻辑是，如果块有命名，那么优先展示命名，否则就展示 content。

1. 第一个推测是「侧边栏工具」插件添加的

   

2. 第二个可能是你安装了「书签 +」插件，该插件默认会隐藏内置的书签，如果想要显示，请在设置中配置

   

3. 第三个不清楚，只能通过禁用插件做排除法

感觉最好的方法是 github action 里配置在编译完后把 image 文件传到 release 当中？不确定能不能做。