v74 端上删掉家谱 + 名册页头改「醒目搜索 + 添加」
用户 2026-10-21：「算了，你画不好。这个功能直接从鸿蒙端去掉吧，不要了。 这样名册这个功能，进来以后，上面就是搜索和添加按钮，搜索，做的醒目一点， 现在看不清。家谱和名册的标签，都不要了。家谱的相关功能，都删除。」 家谱链路整条删除（不是隐藏）： - 删 common/KinLayout.ets、components/FbKinGraph.ets 两个源文件 - 删 Types 的 FbKinPerson / FbKinGraph / FbKinRelation、FbParse 的 parseKin - 删 FbModuleLoad 路由、FbModuleRepo 模块名、FbSyncAll 预同步清单里的 kin - 删 DemoData 的 FB_DEMO_KIN_RELATIONS、Theme/Settings 的家谱图标映射 - 删死资源 fb_ic_kin.png - Index 的 kin 分支去掉（不再有「名册/家谱」两个模块共用一个页面） - FbPeoplePage：删 subView 分段切换、kinHeader/kinView、loadKin、segBtn； openDetail 不再借家谱字段兜底，改成纯 id 占位 + 异步补全 （保留"本地没缓存也要立刻开浮层"，那是 v73 修过的"点了没反应"） 名册页头： - 第一行就是搜索 + 添加，上面不再有任何东西 - 搜索框从「看不清」改成醒目：白底 #FFFFFF（原来 inputBg 与页面米色几乎同色 ⇒ 没有边界）、1.5 主题色描边、高度 36→44、图标 15→18 并染主题色、 字号 fontSmall→fontBody、提示词收短成「搜索姓名 / 首字母 / 手机」 验证： - ArkTS 静态守卫 917/0（新增 6 条：家谱五条链路全清 + 搜索框三个具体数值） - 反向验证 154/0（新增 7 条注入全部有效；另修好两条因代码演进失效的旧锚点） - 编译 BUILD SUCCESSFUL + 装机 install bundle successfully - 真机 v74 探针 22/0（高度实测 44.2vp、白底、占屏 66%、同排对齐、 家谱在页面与抽屉里都不存在、搜索输入与清空真的生效） 顺带修掉探针三处假红（都不是应用问题，是量错了节点）： - 搜索框在界面树里是两层，TextInput(75px) 只是内部输入区， 白底容器 Row(138px) 才是盒子；只按"有文字/可点"收集会把它漏掉 - uitest uiInput inputText 是 (x,y,text) 三参数，只给文本会静默不输入 - 空态文案是「换个关键词试试…」，按"没有/找到"判永远为假
This commit is contained in:
@@ -53,7 +53,6 @@ export const FB_MODULE_PATH: Record<string, string> = {
|
||||
'books': '/api/v1/books',
|
||||
'notes': '/api/v1/notes',
|
||||
'notifications': '/api/v1/notifications',
|
||||
'kin': '/api/v1/kin',
|
||||
};
|
||||
|
||||
/**
|
||||
|
||||
@@ -26,7 +26,7 @@ const TAG: string = 'FbModuleRepo';
|
||||
/** 模块名（同时也是缓存键） */
|
||||
export type FbModuleName =
|
||||
| 'home' | 'calendar' | 'days' | 'tasks' | 'trips'
|
||||
| 'ledger' | 'resources' | 'books' | 'notes' | 'notifications' | 'kin';
|
||||
| 'ledger' | 'resources' | 'books' | 'notes' | 'notifications';
|
||||
|
||||
/** 一次加载的结果 */
|
||||
export interface FbModuleLoad {
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
import {
|
||||
FbAccount, FbAnniversaryItem, FbBookItem, FbBookNoteItem, FbCalEvent, FbHomeData, FbKinChip,
|
||||
FbKinGraph, FbKinPerson, FbMark,
|
||||
FbMark,
|
||||
FbLedgerBook, FbLedgerDetail, FbLedgerEntry, FbNoteItem, FbNotificationItem, FbResourceItem,
|
||||
FbTaskItem, FbTripItem, FbWeather, FbStat, FbMemoryItem, FbRecentDay,
|
||||
} from '../model/Types';
|
||||
@@ -437,58 +437,6 @@ export function parseLedgerEntries(json: string): FbLedgerDetail {
|
||||
return d;
|
||||
}
|
||||
|
||||
/**
|
||||
* 家谱 → FbKinGraph。
|
||||
*
|
||||
* ⚠️ 服务端给的关系是**数组**（`parents`/`children`/`spouses`/`siblings`
|
||||
* 全是 id 数组），端上直接用 —— 不重新推导。
|
||||
* ⚠️ 亲属称谓（`label`）也**由服务端算**（`Kinship::label`），
|
||||
* 端上**不重算**：那依赖整个家族图谱，两边算法不一致就会出现
|
||||
* "App 说堂兄、网页说表兄"。
|
||||
*/
|
||||
export function parseKin(json: string): FbKinGraph {
|
||||
const root: Record<string, Object> | null = asObject(json);
|
||||
const empty: FbKinGraph = { meId: 0, people: [], total: 0 };
|
||||
if (root === null) {
|
||||
return empty;
|
||||
}
|
||||
const rows: Record<string, Object>[] =
|
||||
arr<Record<string, Object>>(root['people'] as Record<string, Object>[]);
|
||||
const people: FbKinPerson[] = [];
|
||||
for (const r of rows) {
|
||||
people.push({
|
||||
id: n(r['id'] as number),
|
||||
name: s(r['name'] as string),
|
||||
shown: s(r['shown'] as string) !== '' ? s(r['shown'] as string) : s(r['name'] as string),
|
||||
label: s(r['label'] as string),
|
||||
gen: n(r['gen'] as number),
|
||||
avatarColor: s(r['avatar_color'] as string),
|
||||
// v73：家谱卡片要显示头像（服务端一直返回，以前画圆点没解析）
|
||||
avatar: s(r['avatar'] as string),
|
||||
/* 🔴 v73：**不能**用 `n()` —— 它把 null/undefined 折成 0，
|
||||
而服务端的户号 `unit_of` 是**从 0 开始**编号的（户 0 是真实的一户）。
|
||||
⇒ 用 `n()` 会让"字段缺失"与"第 0 户"变成同一个值，
|
||||
布局层就无法区分，线上实测表现为「我与妻子被拆成两户」。
|
||||
这里统一成 -1 表示"没有户号"，布局层只判 `>= 0`。
|
||||
⚠️ 别改回 `n(...)`，也别在布局层用 `> 0`。 */
|
||||
unit: r['unit'] !== null && r['unit'] !== undefined ? n(r['unit'] as number) : -1,
|
||||
// ⚠️ 从 `Record<string, Object>` 里取值必须**显式断言**成目标类型 ——
|
||||
// ArkTS 不会自动把 `Object` 收窄成 `number[]`（编译期报
|
||||
// "Argument of type 'Object' is not assignable to 'number[]'"）。
|
||||
parents: idList(r['parents'] as number[]),
|
||||
children: idList(r['children'] as number[]),
|
||||
spouses: idList(r['spouses'] as number[]),
|
||||
siblings: idList(r['siblings'] as number[]),
|
||||
});
|
||||
}
|
||||
const g: FbKinGraph = {
|
||||
meId: n(root['meId'] as number),
|
||||
people: people,
|
||||
total: n(root['total'] as number),
|
||||
};
|
||||
return g;
|
||||
}
|
||||
|
||||
/** id 数组的容错转换（服务端可能给 null） */
|
||||
function idList(v: number[] | null | undefined): number[] {
|
||||
const xs: number[] = arr<number>(v);
|
||||
|
||||
@@ -87,21 +87,18 @@ const MODULE_CN: Record<string, string> = {
|
||||
'books': '藏书',
|
||||
'notes': '笔记',
|
||||
'notifications': '通知',
|
||||
'kin': '家谱',
|
||||
'home': '首页',
|
||||
};
|
||||
|
||||
/**
|
||||
* 走通用缓存的模块（观影 / 名册有实体表，单独走）。
|
||||
*
|
||||
* 🔴 `kin`（家谱）**必须在**这里（v59 补的）：用户要的是"把所有数据都同步下来"，
|
||||
* 而家谱页原来只在**打开时**才拉 —— 离线进去是一片空白。
|
||||
* 它的数据来源与名册同源（`persons` / `relations` / `nicknames`），
|
||||
* 所以服务端 `CHANGE_TABLES['kin']` 用的是同一批表：名册一变，家谱跟着重拉。
|
||||
* ⚠️ v74：`kin`（家谱）已从端上删除，这里一并移除 —— 否则每次全量同步
|
||||
* 都会去拉一个端上已经没有任何页面消费的接口。
|
||||
*/
|
||||
const CACHE_MODULES: string[] = [
|
||||
'calendar', 'tasks', 'days', 'trips', 'ledger', 'resources', 'books', 'notes',
|
||||
'notifications', 'kin',
|
||||
'notifications',
|
||||
];
|
||||
|
||||
/** `GET /api/v1/changes` 的响应 */
|
||||
|
||||
Reference in New Issue
Block a user