发现来源
实施 #3871 (toPredicateInput 对已是 ${…} 模板的字符串二次包裹)时,按「规则消费半径」
清点 toPredicateInput 的全部调用点。#3871 正文列了七个,实际还有第八个:
packages/plugin-detail/src/renderers/record-alert.tsx:140-141
const predicateInput = toPredicateInput ( props . visible ) ;
const passesPredicate = useCondition ( predicateInput , { record } ) ;
// :193
if ( predicateInput !== undefined && ! passesPredicate ) return null ;
这一处与其它落点一样中了 #3871 :visible: '${…}' 走 fail-soft(不传 throwOnError),
二次包裹后的字符串解析失败被 catch 原样退回,Boolean(非空串) 恒 true —— 一条作者写了
visible 想按条件收起的 record 横幅永远显示 。生产端缺陷已由 #3871 的 PR 一并治好
(改的是共享归一器),本单不是那个缺陷 。
本单要记录的是:这一面的谓词判定从它自己的测试里根本观察不到
packages/plugin-detail/src/renderers/__tests__/record-alert.test.tsx:32-46 把
@object-ui/react 整个 mock 掉,其中谓词管道的两端一起被替成了替身 :
vi . mock ( '@object-ui/react' , ( ) => ( {
// …
useCondition : ( _input : unknown , _scope : unknown ) => stub . predicate . passes ,
toPredicateInput : ( visible : unknown ) => {
stub . predicate . input = visible ; // 仅记录入参
return visible ; // 恒等函数
} ,
// …
} ) ) ;
于是:
toPredicateInput 被换成恒等函数 —— 归一(以及 toPredicateInput 对已经是 ${…} 模板的字符串二次包裹,动作面的谓词一律判成 true(visible 永远显示 / disabled 永远置灰) #3871 的二次包裹)在这个 suite 里
根本不发生;
useCondition 被换成常量 stub.predicate.passes —— 求值也不发生。
该面只剩「渲染器有没有把 props.visible 传下去」这一个可断言点(stub.predicate.input),
「这个 visible 会得到什么 verdict」完全不可观测。任意归一器缺陷、任意求值缺陷,在这个
文件里都是绿的。这就是 objectstack#4984 家族(fixture 让坏掉的规则保持绿),而
DeclaredActionsBar.test.tsx:22-34 的注释已经把同一个教训写过一遍 —— 它自己曾把
useCondition 钉成常量真,导致 #3835 的真值性缺陷在那个 suite 眼皮底下活了很久,后来
改成用真实的评估入口。record:alert 是同一形状还没被改的那个。
影响判断(observation-class)
建议修法(未裁)
参照 DeclaredActionsBar.test.tsx 与 packages/components/.../__tests__/ 里几个动作面
gate suite 的做法:保留 dispatch / metadata / components 的替身,但让谓词入口用真的
(@object-ui/react 的 toPredicateInput + useCondition,配 PredicateScopeProvider
喂 scope),补上四种形态(false / true / '' / 表达式,两个极性)与 ${…} 拼法的
verdict 钉子。@object-ui/react 的 barrel 对轻量 dom project 是便宜的(components 自己
的 gate suite 就是不 mock 直接 import 的)。
Related: #3871 (发现出处,生产端已修)、#3850 /#3862 (「空谓词 / 已声明门」口径分歧的两单)。
未认领。
发现来源
实施 #3871(
toPredicateInput对已是${…}模板的字符串二次包裹)时,按「规则消费半径」清点
toPredicateInput的全部调用点。#3871 正文列了七个,实际还有第八个:packages/plugin-detail/src/renderers/record-alert.tsx:140-141这一处与其它落点一样中了 #3871:
visible: '${…}'走 fail-soft(不传throwOnError),二次包裹后的字符串解析失败被 catch 原样退回,
Boolean(非空串)恒 true —— 一条作者写了visible想按条件收起的 record 横幅永远显示。生产端缺陷已由 #3871 的 PR 一并治好(改的是共享归一器),本单不是那个缺陷。
本单要记录的是:这一面的谓词判定从它自己的测试里根本观察不到
packages/plugin-detail/src/renderers/__tests__/record-alert.test.tsx:32-46把@object-ui/react整个 mock 掉,其中谓词管道的两端一起被替成了替身:于是:
toPredicateInput被换成恒等函数 —— 归一(以及 toPredicateInput 对已经是${…}模板的字符串二次包裹,动作面的谓词一律判成 true(visible 永远显示 / disabled 永远置灰) #3871 的二次包裹)在这个 suite 里根本不发生;
useCondition被换成常量stub.predicate.passes—— 求值也不发生。该面只剩「渲染器有没有把
props.visible传下去」这一个可断言点(stub.predicate.input),「这个
visible会得到什么 verdict」完全不可观测。任意归一器缺陷、任意求值缺陷,在这个文件里都是绿的。这就是 objectstack#4984 家族(fixture 让坏掉的规则保持绿),而
DeclaredActionsBar.test.tsx:22-34的注释已经把同一个教训写过一遍 —— 它自己曾把useCondition钉成常量真,导致 #3835 的真值性缺陷在那个 suite 眼皮底下活了很久,后来改成用真实的评估入口。record:alert 是同一形状还没被改的那个。
影响判断(observation-class)
${…}模板的字符串二次包裹,动作面的谓词一律判成 true(visible 永远显示 / disabled 永远置灰) #3871)已在生产端修掉,record:alert 随之恢复按取值判定。
visible语义(含「predicateInput !== undefined才算已声明门」这条与 动作
disabled的「已声明」判定用!= null,disabled: ''把按钮永久置灰(#3492 同族的另一半 predicate,探针实证) #3842 / 「空谓词」在三处有三种范围:disabled: { dialect: 'cel', source: '' } 仍被判成已声明的门 → 永久置灰(#3842 修完后的残留,需先裁) #3850 家族口径相关的判断)没有任何活钉子。下一次归一器或useCondition侧改动打坏它,CI 不会红。finding记录、不挂pm:queue,由 PM 的 triage 轮定级。建议修法(未裁)
参照
DeclaredActionsBar.test.tsx与packages/components/.../__tests__/里几个动作面gate suite 的做法:保留 dispatch / metadata / components 的替身,但让谓词入口用真的
(
@object-ui/react的toPredicateInput+useCondition,配PredicateScopeProvider喂 scope),补上四种形态(
false/true/''/ 表达式,两个极性)与${…}拼法的verdict 钉子。
@object-ui/react的 barrel 对轻量domproject 是便宜的(components 自己的 gate suite 就是不 mock 直接 import 的)。
Related: #3871(发现出处,生产端已修)、#3850 /#3862(「空谓词 / 已声明门」口径分歧的两单)。
未认领。