后端方案中需要新增的内核接口麻烦描述一下入参出参。

另外，这里的 //!js 是参考 sh 吗？

可能在前端开发看来会理解为 非js 😂

后端方案中需要新增的内核接口麻烦描述一下入参出参。

另外，这里的 //!js 是参考 sh 吗？

可能在前端开发看来会理解为 非js 😂

关于出入参数，也许可以参考一下 /api/search/searchEmbedBlock 的接口？比如 searchEmbedBlock 的输入是

{
    embedBlockID: string,
    stmt: string,
    headingMode: 1 | 0,
    excludeIDs: [item.getAttribute("data-node-id"), protyle.block.rootID],
    breadcrumb: boolean
}

可以仿照这个接口，直接输入给定的 block id

{
    embedBlockID: string,
    includeIDs: string[],
    headingMode: 1 | 0,
    breadcrumb: boolean
}

至于输入和 searchEmbedBlock 保持一致，都是吧。

{
	blocks: blocks
}

那个 //!js 确实就是无脑模仿 sh，当时如果不合适也可以换成别的，比如就一个 //js；或者不一定用 shenbang，用块自定义属性判断也行。😂

能否来一段脚本示例，比如完成某个功能的，这样我们好具体再讨论看看。

能否来一段脚本示例，比如完成某个功能的，这样我们好具体再讨论看看。

以下面这个例子为例，这个是我使用 RunJs 插件运行的，这个插件就是基于 Function 来运行 js 的。

下面这个案例的目标是，将查询的结果，按照笔记本自定义排序的大小来排列。程序最后返回一个 Promise<Blocks[]> 对象，可以在调用 Function 对象的代码中获取返回值。

//js
const notebooks = window.siyuan.notebooks.reduce(
    (target, key, index) => { target[key['id']] = key; return target;},
    {}
);
/**
 * 查询的结果按照文档树上笔记本自定义排列的顺序排列
 */
const query = async () => {
    //为了方便测试，加了 order by random()
    let blocks = await api.sql(`
    select * from blocks where created like '20231116%' order by random() limit 16`);
    blocks.sort((b1, b2) => notebooks[b1.box].sort - notebooks[b2.box].sort);
    console.log(blocks.map((b) => {return {box: notebooks[b.box].name, content: b.content};}));
    return blocks;
}
//返回一个 block 列表，嵌入块就根据这个 block 的内容和顺序来展示
return query();

前端获取到返回的 Block[] 后，可以将对应的 id 传入includeIDs参数，从而来要求内核获取相应的笔记内容。

实际操作的时候，还可以做一些简化，比如可以允许用户只编写 query 函数内部的内容，然后前端部分将其包裹在一个 async () => {${code}} 内部从而规避 js 不能在顶层域中 await 的限制。

感谢，我还需要确认下，需要内核新开接口主要原因是 /api/query/sql 接口返回不了嵌入块接口需要的格式对吧，后半段要使用已有嵌入块渲染的代码？

感谢，我还需要确认下，需要内核新开接口主要原因是 /api/query/sql 接口返回不了嵌入块接口需要的格式对吧，后半段要使用已有嵌入块渲染的代码？

对，或者更确切的说是由于 SQL 语法本身的一些缺陷，有些复杂一点的查询难以或者无法实现；希望可以通过引入 js 的程序逻辑来增强查询的能力。

嗯，逻辑增强我知道，上面主要问的是实现上的参数格式。这样吧，我们再考虑看看，也许下个特性版 v2.11.0 就安排上。

实现方案：

• 使用 //js 作为标识
• 使用内核接口 /api/search/getEmbedBlock Add internal kernel API /api/search/getEmbedBlock #9681

前端 @Vanessa219

是否还可以有另外的方案？

这里能否直接由js，给出符合渲染需要的数据格式。不需要js来拼装sql？

是否还可以有另外的方案？

这里能否直接由js，给出符合渲染需要的数据格式。不需要js来拼装sql？

这个图是前端方案。不过目前来看官方选择的不是这个方案，而是另外一个后端方案。

目前前端支持 return Promise 或者 array

//!js 
return ["20230506210010-houyyvy"]

//!js 
const query = async () => {
    let blocks = await fetchSyncPost("/api/system/getConf", {});
    return ["20230506210010-houyyvy"]
}
return  query()

能否进一步解偶，直接由js运行getEmbeBlock？

目前是通过执行 js 获取 id 数组，进一步解耦要如何做？

初步想法是嵌入块直接使用js返回的html，但是从代码来看，/api/search/getEmbedBlock 的返回结果好像不是html数组
，使用的renderEmbeBlocks也不是返回html，而是直接操作protyle，emmm，感觉要改还是需要仔细想想怎么操作。

现在这个方式我觉得还行吧，如果是想一步到位获取组装好的嵌入块结构，后续我们可以再提供其他接口。

我先研究一下接口，还不知道真的返回了什么，新版还没测试。

主要想法不是在内核返回了什么，而是嵌入块能显示什么能否自定义。比如说，能否直接显示一个表格？

那恐怕不行，这个和编辑器相关。

嗯嗯，顺便把返回空的情况处理一下，不要再走 renderEmbed 即可。你直接 PR 吧。

还需要一个api来更新块的content，目前sql api只能查询，无法执行update操作。

@zxhd863943427 你说的是内核还是前端？

前端，需要一个新的api更新块的content，便于索引内容。

话说其实挂件块也是需要这个api的。

是 api/transactions 这个么？

并不是，是 sqlite 的 blocks 表里的 content 字段，这个是用来搜索的字段，自定义渲染内容最好能自己更新这个字段，才能被搜索到。如果直接写在备注、别名等位置，虽然可以达成搜索的效果，但是会污染原有的 sy 文件。

@zxhd863943427 你说的是 js 嵌入块需要更新 content 字段对吧？这里目前是不支持自动索引的，因为 go 里面没法执行 js：

所以是需要加个接口来主动更新 content 字段？

对的，需要一个接口，至少要能实现这种操作：

 fetchSyncPost('/api/query/updateContent',{"id": id, "content": content})

执行 searchEmbedBlock/getEmbedBlock 的时候后端会自动索引的，怕是没有必要重复索引了：

但是，searchEmbedBlock/getEmbedBlock 自动索引的内容和自定义渲染的内容可能是不一样的。

那等晚点我们还是提供一个更新 content 的内核接口吧。

另外，api/search/getEmbedBlock的返回感觉缺了好多值：

 "block": {
                    "box": "20230917171404-1s8stgn",
                    "path": "/20231122202402-vcooo3s.sy",
                    "hPath": "test/2222222",
                    "id": "20231123131215-t1m9qa5",
                    "rootID": "",
                    "parentID": "",
                    "name": "",
                    "alias": "",
                    "memo": "",
                    "tag": "",
                    "content": "\u003cdiv data-node-id=/div\u003e...",
                    "fcontent": "",
                    "markdown": "而言，插件主要面向程序功能扩展，不面向内容块扩展。",
                    "folded": false,
                    "type": "NodeParagraph",
                    "subType": "",
                    "refText": "",
                    "refs": null,
                    "defID": "",
                    "defPath": "",
                    "ial": {
                        "alias": "11",
                        "bookmark": "111",
                        "custom-avs": "20230808232238-9qwehxq,20231124153111-pdtnnfo",
                        "custom-block": "1111",
                        "custom-temp": "111",
                        "id": "20231123131215-t1m9qa5",
                        "memo": "222",
                        "name": "111",
                        "updated": "20231123133525"
                    },
                    "children": null,
                    "depth": 0,
                    "count": 0,
                    "sort": 0,
                    "created": "",
                    "updated": "",
                    "riffCardID": "",
                    "riffCard": null
                },

什么部分是会正确返回，什么只是留一个空字符串，这个能说明吗

好像提供更新 content 的接口会有问题，因为这个 content 是和 block 绑定的，如果提供更新 content 的接口的话 block 变动后就不一致了。

嵌入块返回的结果很多字段没有填充，前端目前没有用上的就不填充了。

好像提供更新 content 的接口会有问题，因为这个 content 是和 block 绑定的，如果提供更新 content 的接口的话 block 变动后就不一致了。

额，不乱用应该没问题，毕竟自定义渲染肯定是每次更新都会重新调用一次。

改了原块就会被自动覆盖，失去效果了。数据库上最好是只读单向的，仅从 block -> content 方向索引，否则后面可能会引起其他问题。

等等，和block绑定，是哪个block？

编辑器里面的 block

为什么getEmbedBlock没有违反这个规则呢？

searchEmbedBlock/getEmbedBlock 仅更新嵌入块的 content，不能更新其他块。

那能否同样提供一个能自定义内容、仅更新嵌入块的 content的api？

能是能，就是感觉破坏单向的设计怕后面出事 😂

后面试试这个接口 #9736

@Vanessa219 @88250 该功能的具体使用方法是否未写入用户手册中❓

没有写，哪位有时间的话帮忙补充一下吧，谢谢。