Skip to content

record:activity 的 feed 结构上不可能有内容——11 个声明的输入全是空 feed 上的过滤器(objectstack#4413 的形状,第三次) #3165

Description

@os-zhuang

record:activity 是 curated public 契约里的 57 个 block 之一,注册时声明了 11 个输入types / filterMode / limit / showCompleted / unifiedTimeline / showCommentInput / enableMentions / enableReactions / enableThreading / showSubscriptionToggle / showFilterToggle)。它们全部是同一个 feed 上的过滤器和开关,而那个 feed 在任何路径上都恒为空

证据

  1. 渲染器把 items 写死了。 packages/plugin-detail/src/renderers/record-activity.tsx:41

    useRecordContext();                       // 调了,结果被丢弃
    return <RecordActivityTimeline items={[] as any} config={schema as any} />;
  2. 底层组件不取数。 RecordActivityTimelineitems 是 prop,整个文件没有任何 dataSource / sys_activity 访问。

  3. 文件头的说明是假的。 同一个文件第 10 行写着 "Real data wiring (sys_activity / sys_comment polling) lives inside that component" —— 不在。这一句就是缺陷本身。

  4. 没有宿主在喂它。 buildDefaultPageSchema.ts:614 发出的节点是 { type: 'record:activity' }不带任何 props;而触发这一句的 options.showActivity 在生产代码里从来没有被设成 true(只有该 builder 自己的测试设过)。对比同族的两个宿主供数 block——record:discussion 的 items 来自 app-shell RecordDetailView 挂的 DiscussionContextProviderrecord:reference_railentriesbuildDefaultPageSchema:804 注入——它们的宿主路径都是真的,这个没有。

  5. 行为证据。 apps/console/src/__tests__/record-block-record-reach.test.tsxrecord:* 家族与非 objectName 绑定的行为证据——binding-reach 覆盖 14→24/57,#4413 的原始形态不再是假设 #3149 第 3a 层)把它挂在 RecordContextProvider 下、绑两条不同的记录,两次渲染 DOM 逐字节相同、数据调用都是零。

为什么这条值得单独开

声明了、发布进 sdui.manifest.json、AI 作者会照着写,运行时什么都没有——这正是 objectstack#4413 的形状,只不过换了个 block。而 check:react-declaration-parity 看不见它(那道门禁比的是两份声明,objectstack#4472),public-block-binding-reach.test.tsx 也看不见它(record:* 家族按设计从 RecordContext 取数,裸挂载探不到)。

建议的修法

镜像同目录下 record:history 已有的自取数路径(record-history.tsx:77-110):dataSource.find('sys_activity', { $filter: { object_name, record_id }, $orderby, $top }),把行映射成 FeedItem,并让 types / limit / showCompleted / unifiedTimeline 真正参与过滤。宿主已经传 entries 的场合(像 record:history 那样)优先用宿主的。

注意别把修一半当修好showCommentInput 需要 onAddCommentenableReactions / enableThreading 需要各自的 handler,读路径接上之后这些写路径开关仍然是惰性的。要么一并接(走 DiscussionContext 已有的那套 handler),要么在注册处/文档里把它们记成已知空档——不要留成"看起来能配",那就是本 issue 的成因再来一次。

落地前的临时状态

record-block-record-reach.test.tsxNO_RECORD_REACH 台账里带着这一条,写明了理由。台账是双向断言的:这个 block 一旦开始响应绑定记录,那条测试就会失败,直到把台账条目删掉——所以修完不会忘记销账。

参考

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions