上一笔我凭"两侧导航都没有徽标"把刚写好的徽标**撤回**了。那是错的:
`client/electron/src/components/Sidebar.tsx:88-95,111-125` 明确有——
```
const badge = isComm ? unread + pendingPerms
: modes.includes('contacts') ? contacts.length : 0;
const badgeTone = isComm && pendingPerms > 0 ? 'perm' : isComm ? 'unread' : 'plain';
```
并且是 `absolute top-0.5 right-1` 压在导航项右上角,`>99` 显示 `99+`。
我当时只看了底栏 `NavItem`(那里确实没有),就把结论推到了"两侧都没有"。
## 补的东西
- 新增**纯逻辑** `model/NavItems.ts` 的 `navBadgeCount` / `navBadgeTone` / `navBadgeText`,
逐条对齐 WebUI 的口径:
· **通信** = 未读 + 待决策(两类"要动手"合起来);
· **联系人** = 联系人数;日历/「我的」= 0(没有徽标);
· 色调:待决策**橙**(有人卡在那儿等)优先于未读**红**(只是还没看);
· 负数当 0(计数来自网络,不假设它干净);`>99` → `99+`。
- **两侧**(底栏 `MainPage.NavItem` + 宽屏 `WideSidebar.NavItemBuilder`)都接上,
且读**同一组** AppStorage 键 —— 两处各算一套,数字迟早对不上,而用户同时看得到它们。
- 计数发布走 `AppStorage`(单向:窗格写、导航栏读),与 `KEY_WINDOW_INSETS` 同一套机制。
不把这两个数提到 `MainPage`:那样"从没进过通信页"也会去发请求。
- 徽标位置对齐 WebUI 的 `absolute top-0.5 right-1`(压在项的右上角)。
★ 第一版我排在文字**下面**,截图一眼可见那颗 3 掉到了「联系人」标签底下、
还把 48vp 的项撑高了 —— 方阵节奏乱掉。
## 判据(harmony-widescreen 6 → 7)
第 ⑦ 条**直接执行**鸿蒙侧的纯函数,且期望值在测试里**独立算一遍**
(不复用被测函数,否则是"用实现验实现")。
★ 接线部分我写错过一次,变异测试当场拆穿:第一版只判
`assert.match(src, /navBadgeCount\(/)` —— 把**渲染处**的调用换成 `0`
(徽标永远不显示),文件里仍留着一处调用,判据照样全绿。
⇒ 改成判**把值交给 Text 的那一行**,并且认出两侧写法不同(底栏走 helper
`Text(this.navBadgeOf(key))`,侧栏就地内联 `Text(navBadgeText(navBadgeCount(...)))`)。
**4 个变异方向全咬**:通信漏算待决策 ⇒ 红;色调优先级写反 ⇒ 红;
侧栏渲染处换空 ⇒ 红;底栏渲染处换空 ⇒ 红。
设备实测:侧栏「联系人」显示红 **3**(3 个联系人),位置在图标右上角。
279 lines
17 KiB
JavaScript
279 lines
17 KiB
JavaScript
// 宽屏侧栏图标轨(WideSidebar)判据 —— 一比一复刻 WebUI 的 `Sidebar`(60px 图标轨)。
|
||
//
|
||
// WebUI 的 `Sidebar`(components/Sidebar.tsx)是 60px 宽的图标列:
|
||
// 品牌标(顶) / 通信·日历·联系人(中) / 设置(底)
|
||
// 选中态 = 图标+文字变色 + 品牌浅底,**不加背景块/指示条**。
|
||
//
|
||
// 鸿蒙侧原来是**没有**宽屏布局的(只有底部导航条),WideSidebar 补的就是
|
||
// "宽屏模式"这半:≥768vp 时 MainPage 挂侧栏、藏底部条(见 MainPage.build 的 onAreaChange)。
|
||
// 这条判据钉的是 Sidebar 自己的形状:宽 60vp、三项导航 + 设置、选中态只换颜色。
|
||
|
||
import { code, prose, stripComments } from './lib/read.mjs';
|
||
import { readFileSync } from 'node:fs';
|
||
import { dirname, join } from 'node:path';
|
||
import { fileURLToPath } from 'node:url';
|
||
import { test } from 'node:test';
|
||
import assert from 'node:assert/strict';
|
||
|
||
const HERE = dirname(fileURLToPath(import.meta.url));
|
||
const ROOT = join(HERE, '..', '..', '..');
|
||
const HARMONY_ETS = join(ROOT, 'client/harmony/entry/src/main/ets');
|
||
|
||
const read = p => prose(join(HARMONY_ETS, p));
|
||
|
||
/** 取某个成员/方法正文(按行切到下一个成员声明) */
|
||
function memberBody(src, signature) {
|
||
const lines = src.split('\n');
|
||
const start = lines.findIndex(l => l.includes(signature));
|
||
assert.ok(start > 0, `要能找到 ${signature}`);
|
||
let stop = lines.length;
|
||
for (let i = start + 1; i < lines.length; i++) {
|
||
if (/^ (@Builder|build\(|NavItemBuilder\()/.test(lines[i])) { stop = i; break; }
|
||
}
|
||
return lines.slice(start, stop).join('\n');
|
||
}
|
||
|
||
test('① 宽度:SIDEBAR_WIDTH = 60vp(WebUI 的 `w-[60px]` 是同一数字)', () => {
|
||
const sidebar = read('pages/WideSidebar.ets');
|
||
const code_ = stripComments(sidebar);
|
||
assert.match(code_, /export const SIDEBAR_WIDTH: number = 60\s*;/, '要导出 60 这个常量');
|
||
const main = read('pages/MainPage.ets');
|
||
assert.match(main, /WideSidebar\(/, 'MainPage 要真正挂 WideSidebar');
|
||
});
|
||
|
||
test('② 四项导航(与底栏同源):不再有单列的"设置"入口', () => {
|
||
/*
|
||
* ★★ 2026-09-18 重写。原来这条判的是「三项导航 + 设置按钮」,
|
||
* 依据是"设置单列在下面、遍历 NAV_ITEMS 会出现两个 person 图标"。
|
||
* 那个依据**两半都错**:
|
||
* · `NAV_CONTENT_ITEMS = NAV_ITEMS.slice(0, NAV_CONTENT_COUNT)` 而
|
||
* `NAV_CONTENT_COUNT = 4` ⇒ **四项全在**(含「我的」),不存在"只有前三项";
|
||
* · 单列的"设置"走 `onSettings → pushUrl('pages/SettingsPage')`,
|
||
* 而那正是用户 2026-09-17 报过的「我的页面完全没有遵守 nav 的导航规则」
|
||
* (底栏那一支改成了窗格,侧栏这一支漏了)。
|
||
*
|
||
* WebUI `Sidebar.tsx` 的真实形状:`navItems` 三项 + **底部一簇**
|
||
* (账号头像 / 主题切换 / 退出)。「我的」在 WebUI 是 `viewMode === 'account'`,
|
||
* 由侧栏底部那个**头像按钮**进入 —— 也就是说它是**导航项**,不是"推出去的页"。
|
||
* 鸿蒙的对应物是第 4 项「我的」窗格(与底栏一致)。
|
||
*/
|
||
const sidebar = read('pages/WideSidebar.ets');
|
||
const code_ = stripComments(sidebar);
|
||
assert.match(code_, /ForEach\(NAV_CONTENT_ITEMS,/,
|
||
'侧栏要遍历 NAV_CONTENT_ITEMS(与底栏同一个清单 —— 两处各留一份会漂移)');
|
||
// 品牌标:WebUI 是 `<button data-testid="brand-mark"><BrandMarkIcon/>` —— 可点 + brandMark 图标
|
||
assert.match(code_, /iconName: 'brandMark'/, '要有品牌标(WebUI `brand-mark` 的对应物,图标是 brandMark)');
|
||
// 「我的」必须在侧栏里作为一个**导航项**出现,且走 onSelect 而不是推页
|
||
assert.ok(!/onSettings/.test(code_),
|
||
'侧栏不许留 onSettings(它推 `pages/SettingsPage` ⇒ 侧栏整条消失,正是用户报过的形状)');
|
||
/*
|
||
* 「我的」由上面那个 `ForEach(NAV_CONTENT_ITEMS)` 覆盖(`NAV_CONTENT_ITEMS`
|
||
* 含第 4 项)—— 所以这里判的是"没有另起一个推页入口",
|
||
* 以及 onSelect 能把 index 传到第 4 项(`normalizeNavIndex` 不截到 3 项)。
|
||
*/
|
||
assert.match(code_, /onClick\(\(\) => \{ this\.onSelect\(index\); \}\)/,
|
||
'导航项点击要原样传 index(第 4 项「我的」因此走 onSelect(3) = 窗格)');
|
||
// 品牌标点它要回第一项(WebUI `onClick={() => setViewMode('inbox')}`)
|
||
assert.match(code_, /onClick\(\(\) => \{ this\.onSelect\(0\); \}\)/,
|
||
'品牌标点击要回收件箱(WebUI brand-mark 的一致习惯:点左上角 logo 回家)');
|
||
});
|
||
|
||
test('③ 侧栏选中态 = **浅蓝底块** + 变色(与底栏"只变色"是两条纪律)', () => {
|
||
/*
|
||
* ★★ 2026-09-18 重写。原来这条写着「选中态只换颜色……不加背景块」,
|
||
* 并引"WebUI Sidebar 本就是纯图标轨"为依据 —— **依据是编的**。
|
||
*
|
||
* `client/electron/src/index.css:1595-1606` 的原话:
|
||
* 「底部导航的选中态**只换颜色**……只作用在 `.narrow-nav` 上:宽屏侧栏是
|
||
* 48px 宽的竖条,图标底下那一块底色是它**唯一的选中线索**,
|
||
* 所以"只变色"不能无差别推广到所有 `.nav-item`。」
|
||
* 而 `.nav-item[data-active='true'] { background-color: rgb(var(--nav-active-bg)) }`
|
||
* 就是那块底色(`--nav-active-bg: 219 234 254` = #DBEAFE)。
|
||
*
|
||
* ★ 这条判据现在**直接读 WebUI 的 CSS 拿真实值**,而不是引自己写的注释 ——
|
||
* 上一版之所以能一直绿,就是因为"依据"是一句话,没人拿它跟 WebUI 对。
|
||
*/
|
||
const sidebar = read('pages/WideSidebar.ets');
|
||
const code_ = stripComments(sidebar);
|
||
|
||
// 从 WebUI 的真实源码里取侧栏选中底色(不写死,改了两边一起动)
|
||
const css = readFileSync(
|
||
join(ROOT, 'client', 'electron', 'src', 'index.css'), 'utf8');
|
||
const m = css.match(/--nav-active-bg:\s*(\d+ \d+ \d+)/);
|
||
assert.ok(m, 'WebUI index.css 要有 --nav-active-bg(侧栏选中底色)');
|
||
const [r, g, b] = m[1].split(' ').map(Number);
|
||
const hex = '#' + [r, g, b].map(v => v.toString(16).padStart(2, '0')).join('').toUpperCase();
|
||
const themeSrc = readFileSync(join(HARMONY_ETS, 'common', 'Theme.ets'), 'utf8');
|
||
assert.match(themeSrc, new RegExp(`navActiveBg: string = '${hex}'`, 'i'),
|
||
`Theme.navActiveBg 要等于 WebUI 的 --nav-active-bg(${hex})`);
|
||
|
||
// 选中态必须**有底块**(WebUI 侧栏唯一的选中线索)
|
||
assert.match(code_, /backgroundColor\(this\.currentIndex === index \? Theme\.navActiveBg : Color\.Transparent\)/,
|
||
'导航项选中要有底块(WebUI `.nav-item[data-active]` 的 --nav-active-bg)—— 侧栏不是底栏,不能只变色');
|
||
|
||
// 文字标签:WebUI `Sidebar.tsx:110` 有 <span>{short}</span>,所以侧栏**有** label
|
||
assert.match(code_, /Text\(label\)/,
|
||
'侧栏导航项要有文字标签(WebUI Sidebar 有 <span>{short}</span>)');
|
||
|
||
// ★ 自检:这三条都必须能判红
|
||
assert.ok(!/backgroundColor\(this\.currentIndex === index \? Theme\.navActiveBg : Color\.Transparent\)/.test(
|
||
'backgroundColor(this.currentIndex === index ? Color.Transparent : Theme.navActiveBg)'),
|
||
'自检:三元式写反了必须判红');
|
||
});
|
||
|
||
test('④ MainPage 接线:宽屏才挂侧栏、宽屏藏底部条、断点 768', () => {
|
||
const main = read('pages/MainPage.ets');
|
||
const code_ = stripComments(main);
|
||
// 宽屏分支:isWide 时才渲染 WideSidebar
|
||
assert.match(main, /if \(this\.isWide\) \{/, '侧栏要包在 isWide 分支里');
|
||
assert.match(code_, /WideSidebar\(\{/, '侧栏要真挂在 build 里(剥注释后仍存在)');
|
||
// 窄屏 x 宽屏:底部条只要窄屏有 —— 两半都是条件式的,不是同时出现
|
||
assert.match(main, /if \(!this\.isWide\) \{/, '底部导航条要包在 !isWide 分支里');
|
||
const both = /if \(this\.isWide\) \{[\s\S]*?if \(!this\.isWide\)/.test(main);
|
||
assert.ok(both, 'isWide 与 !isWide 两分支要在同一个结构里(互斥)');
|
||
// 断点检测
|
||
assert.match(code_, /onAreaChange/, '要用 onAreaChange 实时检测窗口宽度');
|
||
assert.match(code_, />=\s*768/s, '断点是 768(与 WebUI 的 lg 断点同一档)');
|
||
// let为0(宽屏没有底部条,内容 padding 归零)
|
||
/*
|
||
* ★ 2026-09-17:让位方式改了 —— 宽屏不再靠"内容 padding 归零",
|
||
* 而是宽屏时 navReserve 本身变成 0(没有底部条)。
|
||
* 内容窗格必须**满高**,否则内容滑不到条底下、玻璃就没东西可糊。
|
||
*
|
||
* ★ 2026-09-18:窄屏那一支多加了 `windowInsets.navIndicator`(全屏后要让开系统
|
||
* 手势条,见 `harmony-window.test.mjs`)。所以断言改为:**宽屏一定是 0**,
|
||
* 窄屏是 `NAV_CONTENT_RESERVE` **加上避让**(不是写死那个字面表达式)。
|
||
* 写死的话,"加一个正当的避让"与"宽屏忘了归零"会红得一模一样 ——
|
||
* 而这条判据要守的是后者。
|
||
*/
|
||
const reserve = /this\.navReserve = this\.isWide \? 0 : ([^;]+);/.exec(code_);
|
||
assert.ok(reserve, '要按 `isWide ? 0 : <窄屏值>` 的开关式写 navReserve');
|
||
const narrowExpr = reserve[1].trim();
|
||
assert.notEqual(narrowExpr, '0', '窄屏不能归零(窄屏有底部条,列表要让位)');
|
||
assert.match(narrowExpr, /NAV_CONTENT_RESERVE/,
|
||
'窄屏要让条高那么大的位(至少含 NAV_CONTENT_RESERVE)');
|
||
});
|
||
|
||
test('⑥ 邮件列表→详情使用系统 Navigation Auto,不再手搓 Row 分栏', () => {
|
||
const main = read('pages/MainPage.ets');
|
||
const code_ = stripComments(main);
|
||
/*
|
||
* phone / tablet / 2in1 的列表→详情行为交给系统:
|
||
* - 窄宽度自动 Stack(详情覆盖列表,可返回);
|
||
* - 宽窗口自动 Split(列表 + 详情并排)。
|
||
* 断点由 navBarWidthRange + minContentWidth 共同决定,不复制一套 onAreaChange。
|
||
*/
|
||
assert.match(code_, /private navPathStack: NavPathStack = new NavPathStack\(\)/,
|
||
'通信页必须持有 NavPathStack');
|
||
assert.match(code_, /Navigation\(this\.navPathStack\)/,
|
||
'通信页列表/详情必须由原生 Navigation 承载');
|
||
assert.match(code_, /\.navDestination\(this\.DestinationBuilder\)/,
|
||
'Navigation 必须注册邮件详情目标页 builder');
|
||
assert.match(code_, /\.mode\(NavigationMode\.Auto\)/,
|
||
'必须用 NavigationMode.Auto,让系统自动选择 Stack / Split');
|
||
assert.match(code_, /\.navBarWidth\(320\)/,
|
||
'宽屏列表栏应与 WebUI MailList 的 320px 同档');
|
||
assert.match(code_, /\.navBarWidthRange\(\[280, 360\]\)/,
|
||
'列表栏应允许系统在 280–360vp 内适配,而不是固定死布局');
|
||
assert.match(code_, /\.minContentWidth\(360\)/,
|
||
'详情栏最小宽度参与 Auto 断点计算');
|
||
assert.match(code_, /this\.navPathStack\.pushPath\(\{ name: MAIL_DETAIL_ROUTE, param: params \}\)/,
|
||
'选中邮件必须进入 NavPathStack,而不是绕回 router.pushUrl');
|
||
});
|
||
|
||
test('⑤ 宽屏 app-shell 几何:padding/gap/radius 与 WebUI 同值(一比一复刻的骨架)', () => {
|
||
const main = read('pages/MainPage.ets');
|
||
const code_ = stripComments(main);
|
||
/*
|
||
* WebUI 的 `.app-shell`(index.css):
|
||
* padding: var(--pane-gap) → 10px
|
||
* gap: var(--pane-gap) → 10px
|
||
* > * { border-radius: var(--radius-card) } → 14px
|
||
* 宽屏面板之间留缝(壁纸从缝隙露出)、各面板圆角 14。窄屏贴合全屏(无 padding / 无圆角)。
|
||
*/
|
||
// 令牌值要和 WebUI 同值(14/10)
|
||
const theme = read('common/Theme.ets');
|
||
assert.match(theme, /static readonly glassRadius: number = 14/, 'glassRadius = 14(与 WebUI --radius-card 同值)');
|
||
assert.match(theme, /static readonly paneGap: number = 10/, 'paneGap = 10(与 WebUI --pane-gap 同值)');
|
||
// Row 用 space=paneGap(gap)
|
||
assert.match(code_, /Row\(\{ space: Theme\.paneGap \}\)/, '宽屏 Row 用 space=paneGap(与 WebUI gap 同值)');
|
||
// 内容面板圆角只在宽屏启用(窄屏贴合全屏)
|
||
assert.match(code_, /borderRadius\(this\.isWide \? Theme\.glassRadius : 0\)/, '内容面板圆角宽屏 14 / 窄屏 0');
|
||
assert.match(code_, /clip\(this\.isWide\)/, '面板内容要被圆角裁剪(clip 宽屏才开)');
|
||
// 容器 padding 宽屏 paneGap / 窄屏 0(壁纸从缝隙露出)
|
||
assert.match(code_, /left: this\.isWide \? Theme\.paneGap : 0/, '宽屏容器左右 padding paneGap(窄屏 0 贴合全屏)');
|
||
});
|
||
test('⑦ 导航项徽标:取值/色调与 WebUI Sidebar 同口径(纯逻辑,不需要设备)', async () => {
|
||
/*
|
||
* WebUI `Sidebar.tsx:88-95` 的 `badge` / `badgeTone`:
|
||
* `isComm ? unread + pendingPerms : (contacts ? contacts.length : 0)`
|
||
* `isComm && pendingPerms > 0 ? 'perm' : isComm ? 'unread' : 'plain'`
|
||
*
|
||
* ★ 这条判据**直接执行**鸿蒙侧的纯函数(`model/NavItems.ts`,无 SDK 依赖),
|
||
* 并把期望值**在测试里独立算一遍**(不复用被测函数)—— 否则就是"用实现验实现"。
|
||
*
|
||
* 为什么值得单列一条:底栏与侧栏都要显示徽标,而两处若各写一套判断,
|
||
* 同一时刻一个显示"3 / 未读"、另一个显示"3 / 待批",用户会以为哪里出错了。
|
||
* 所以取值与色调都必须来自**同一组纯函数**。
|
||
*/
|
||
const mod = await import(join(HARMONY_ETS, 'model', 'NavItems.ts'));
|
||
const { navBadgeCount, navBadgeTone, navBadgeText } = mod;
|
||
|
||
// ① 通信 = 未读 + 待决策(两类"要动手"合起来,与 WebUI 同)
|
||
assert.equal(navBadgeCount('comm', 5, 2, 0), 7, '通信徽标 = 未读 5 + 待决策 2');
|
||
// ② 联系人 = 联系人数
|
||
assert.equal(navBadgeCount('contacts', 0, 0, 3), 3, '联系人徽标 = 联系人数');
|
||
// ③ 日历 / 我的 没有徽标(日历的"有事"是格子上的点,不是导航栏该喊的)
|
||
assert.equal(navBadgeCount('calendar', 5, 2, 3), 0, '日历不该有徽标');
|
||
assert.equal(navBadgeCount('me', 5, 2, 3), 0, '「我的」不该有徽标');
|
||
// ④ 负数当 0(计数来自网络,不假设干净)
|
||
assert.equal(navBadgeCount('comm', -1, -1, -1), 0, '负数一律当 0');
|
||
assert.equal(navBadgeCount('contacts', 0, 0, -5), 0, '联系人数为负也当 0');
|
||
|
||
// ⑤ 色调:待决策橙(更急)优先于未读红;非通信项是中性
|
||
assert.equal(navBadgeTone('comm', 2), 'perm', '有人的授权在等我 ⇒ 橙(比"还没看"更急)');
|
||
assert.equal(navBadgeTone('comm', 0), 'unread', '只有未读 ⇒ 红');
|
||
assert.equal(navBadgeTone('contacts', 0), 'plain', '联系人数是中性色');
|
||
|
||
// ⑥ 文字:0 → 空串(页面据此不渲染)、>99 → 99+(与 WebUI 同一写法)
|
||
assert.equal(navBadgeText(0), '', '0 要变成空串(否则会渲染一个"0"徽标)');
|
||
assert.equal(navBadgeText(99), '99');
|
||
assert.equal(navBadgeText(100), '99+');
|
||
|
||
/*
|
||
* ⑦ 接线:**两侧**(底栏 NavItem + 宽屏侧栏)都要用这同一组函数。
|
||
* 只在一处接的话,另一个视图里徽标就消失了 —— 而用户两个视图都会用到。
|
||
*/
|
||
const main = stripComments(read('pages/MainPage.ets'));
|
||
const sidebar = stripComments(read('pages/WideSidebar.ets'));
|
||
/*
|
||
* ★ 判**徽标真的被渲染出来**,不是"文件里出现过 navBadgeCount"。
|
||
*
|
||
* 第一版只 `assert.match(src, /navBadgeCount\(/)` —— 变异测试当场证明它不咬:
|
||
* 把渲染处的 `navBadgeCount(...)` 换成 `0`(徽标永远不显示),
|
||
* 文件里仍留着别处的调用,判据照样全绿。
|
||
*
|
||
* 两侧的**写法不同**(都合法),所以按各自形状判:
|
||
* · 底栏 MainPage:走一个 helper —— `Text(this.navBadgeOf(key))`,
|
||
* helper 体内 `navBadgeText(navBadgeCount(...))`;
|
||
* · 宽屏 WideSidebar:就地内联 —— `Text(navBadgeText(navBadgeCount(...)))`。
|
||
* 两边都要判到,且都要判底色来自 `navBadgeTone`。
|
||
*/
|
||
assert.match(main, /Text\(this\.navBadgeOf\(/,
|
||
'底栏要把徽标交给 Text 渲染(光"文件里出现过 navBadgeCount"不算接线)');
|
||
assert.match(main, /navBadgeText\(navBadgeCount\(/,
|
||
'底栏的 helper 要真的用 navBadgeText(navBadgeCount(...)) 算值');
|
||
assert.match(main, /backgroundColor\(navBadgeTone\(/,
|
||
'底栏的徽标底色要由 navBadgeTone 决定');
|
||
|
||
assert.match(sidebar, /Text\(navBadgeText\(navBadgeCount\(/,
|
||
'侧栏要把徽标交给 Text 渲染(光"文件里出现过 navBadgeCount"不算接线)');
|
||
assert.match(sidebar, /backgroundColor\(navBadgeTone\(/,
|
||
'侧栏的徽标底色要由 navBadgeTone 决定');
|
||
// 两侧读**同一组** AppStorage 键(各算一套的话数字会不一致)
|
||
for (const key of ['agentmail.nav.unread', 'agentmail.nav.pending', 'agentmail.nav.contacts']) {
|
||
assert.ok(main.includes(key), `MainPage 要读 ${key}`);
|
||
assert.ok(sidebar.includes(key), `WideSidebar 要读 ${key}(与底栏同一组键)`);
|
||
}
|
||
});
|