Angular+Firebase待办列表如何将@angular/cdk拖拽排序结果存入Firestore

完全可以实现，你现有基于Firestore文档/集合的结构不需要做颠覆性改造，核心是将拖拽完成后的排列顺序映射为可持久化的排序字段，对接拖拽事件的结果同步到Firestore即可，有两个适配不同场景的落地路径：

方案一：固定索引值存储（适配日常规模的Todo列表） #

这是绝大多数Todo类应用的首选实现，逻辑简单、读写成本低：

• Firestore数据结构设计：
  你可以结合现有表结构二选一：
  • 优先推荐在用户Todo集合的父级主文档（比如users/{userId}/todoMeta）中新增todoOrder数组字段，按当前列表顺序存储所有Todo的文档ID，数组的位置直接对应Todo的排列位次。这种结构下单次写入就能完成顺序持久化，成本最低。
  • 备选方案：在每个Todo文档（users/{userId}/todos/{todoId}）中新增sortIndex数值字段，值为该Todo在列表中的排位，比如列表第一项为0，第二项为1，以此类推。
• 拖拽事件对接持久化逻辑：
  在Cdk拖拽的cdkDropListDropped事件回调中，拿到拖拽完成后的本地有序Todo数组后，直接把新的顺序同步到Firestore：
  1. 如果使用主文档存数组的结构：直接把整理好的新Todo ID数组作为值，更新到主文档的todoOrder字段即可，单条写入请求就能完成持久化。
  2. 如果使用单文档存sortIndex的结构：遍历拖拽后的有序Todo列表，为每个Todo匹配新的排位值，用Firestore的writeBatch批量更新所有相关Todo文档的sortIndex字段，避免循环调用单条更新接口产生多余请求。
• 数据读取适配：
  从Firestore拉取Todo数据后，不要依赖Firestore默认的文档创建顺序、ID字典序排序，要按照存储的顺序（数组位次、sortIndex升序）重新排列本地列表后，再绑定给Cdk拖拽组件的数据源。
  简化的核心逻辑参考：

  onTodoDrop(event: CdkDragDrop<TodoItem[]>) {
    // 本地调整数组元素位置
    moveItemInArray(this.todoDataSource, event.previousIndex, event.currentIndex);
    // 整理为需要持久化的顺序格式
    const newTodoOrder = this.todoDataSource.map(item => item.id);
    // 写入Firestore
    this.todoMetaDoc.update({ todoOrder: newTodoOrder });
  }
  

方案二：浮动间隙排序（适配超大规模Todo列表） #

如果你的Todo列表条目数超过数百条，每次拖拽都全量重算所有条目的索引值、批量更新的话请求成本太高，可以改用浮动间隙排序的设计：

• 给每个Todo的排序字段预留足够的数值间隙，比如初始排序值设置为1000、2000、3000，相邻条目之间保留1000的数值差。
• 拖拽调整位置时，不需要重算所有条目的排序值，只要把被拖动的Todo的排序值，设置为它新位置前后两个相邻Todo排序值的中间值即可，比如要把排序值1000的Todo移到2000和3000中间，只要把它的排序值改成2500，单条更新就能完成持久化。
• 当相邻条目之间的数值间隙被完全用完时（比如两个相邻值差1000，中间连续插入了1001个新条目），再触发一次全量的排序值重算即可。

实操避坑提示 #

• 不要把整个Todo列表序列化成单个大文档存储，后续单条编辑Todo状态、内容时会引发整个大文档的读写竞争，容易产生数据覆盖丢失。
• 不要用Firestore自动生成的文档ID字典序作为排序依据，这个顺序和用户手动调整的排列顺序完全无关。
• 拖拽触发的写入操作可以加300ms左右的防抖，避免拖动过程中频繁触发无效写请求。
• 批量更新操作一定要使用Firestore的批量写接口，不要在循环中逐条调用更新方法，减少网络请求次数、降低Firestore的写入配额消耗。

内容的提问来源于stack exchange，提问作者KoboldMines