列表切换要用 master-detail 而非重建列表
两种模型
| 路由详情页 | master-detail | |
|---|---|---|
| 点击卡片 | 进入 /notes/[slug],路由变化 | 只改 selectedId/slug |
| 左列表 | 每次切换重新挂载/排序 | 只加载一次,滚动容器不重建 |
| 代价 | 能直接分享/刷新单篇链接,前进后退自然 | 需自己同步 URL(history.pushState)保留直达链接 |
| 稳定性 | 易出现选中后跳位 | 列表根本不重建,不跳 |
做法
- 左侧列表只加载一次,点击只改选中态;右侧切换当前内容。
- URL 用
history.pushState或轻量路由同步成/notes/slug,保留直达链接。 - 直接打开
/notes/slug时,再初始化选中那一篇。
判据:问题不是「按更新时间排序」,而是「切换时列表被重建」。 正确解法是让列表不重建,而不是取消排序——甚至可以在「离开/切换区/刷新」时才重排。
参考:Mac Notes 也按更新时间排却不明显卡顿,因为它左栏一直在、编辑器切换不驱动左栏重新加载、数据本地增量更新。
相关
- 编辑器初始化会触发假保存 —— 路由重建时编辑器初始化会顺带触发假保存,加重跳位
- 流式更新要合并字段而非替换对象
- 服务端缓存与浏览器缓存的边界 —— 跨栏目切换(页面卸载重建)时,靠浏览器侧内容缓存 + 后台刷新补回体验,而不是让列表接口带回全文
- 过期响应不能覆盖当前编辑内容 —— 缓存化之后要处理返回顺序,避免旧响应盖住新状态
- 复制要区分可见文本与富文本
- 可调与固定的边界按语义划分
- 聊天记录要从底部锚定加载 —— 同为「不要为了数据把整个视图重建/清空」