React应用中如何拆分state避免块编辑器非必要全量重渲染

当前实现的性能瓶颈根源 #

• 全局嵌套状态将文档元信息、所有块的内容耦合在同一个大对象里，任何块的内容变更都会触发Editor组件重渲染
• handleOnInput等回调因为需要依赖闭包内的全局state，无法通过useCallback生成稳定引用，导致传入Block组件的onInput prop每次都是新值，即便Block做了memo优化也会失效，最终所有块全量重渲染
• 跨块操作（如backspace合并相邻块内容）需要读取其他块的状态，进一步加剧了组件层对全局state的依赖，没办法将块的状态做局部隔离
• 单块本地状态方案存在明显缺陷：失焦才同步的逻辑既无法支持实时增量API更新，也会让跨块的状态操作、后续协作编辑的逻辑变得难以实现

对齐后端模型的状态拆分设计 #

后端已经天然将文档与块拆分为独立模型，前端状态完全可以对齐这套结构，从根源上解耦不同块的状态变更影响范围：

拆分后的状态结构 #

• 顶层仅保留文档级元信息：文档id、名称、块的有序id列表（对应后端documentModel）
• 所有块的完整数据（id、类型、内容）独立存储在以块id为键的Map结构中（对应后端blockModel）

拆分后的状态结构示例：

editorState = {
  docMeta: {
    id: '',
    name: '',
    blockIds: [] // 仅存储块的顺序，不嵌套块的完整内容
  },
  blockMap: {
    // key为块id，value为块的完整独立数据
    [blockId]: {
      id: blockId,
      type: '',
      content: []
    }
  }
}

跨块操作的逻辑下沉 #

所有需要读取其他块状态的逻辑（如backspace合并内容）全部下沉到reducer内部处理，组件层的回调不再依赖闭包中的全局state，完全可以生成稳定的引用：

• 组件层触发backspace操作时，只需要dispatch携带当前块id、当前块内容的action，不需要提前读取前一个块的内容做拼接
• reducer内部处理时，直接从状态草稿里查找当前块的位置，提取相邻的前一个块的数据完成内容拼接、块删除操作，整个过程组件层完全不需要接触全量状态

对应的reducer实现示例：

case ReducerActions.deleteBlock: {
  const currentBlockId = action.blockId;
  const currentIndex = draft.docMeta.blockIds.indexOf(currentBlockId);
  // 首个块触发backspace不做合并处理
  if (currentIndex <= 0) break;
  
  const prevBlockId = draft.docMeta.blockIds[currentIndex - 1];
  const prevBlock = draft.blockMap[prevBlockId];
  const currentBlock = draft.blockMap[currentBlockId];
  
  // 拼接相邻块的内容
  prevBlock.content = [...prevBlock.content, ...currentBlock.content];
  // 从顺序列表中移除当前块
  draft.docMeta.blockIds.splice(currentIndex, 1);
  // 从块映射中清除已删除的块数据
  delete draft.blockMap[currentBlockId];
  break;
}

渲染性能优化落地 #

• 通用回调（onInput、onSelect）仅依赖稳定的dispatch方法生成，通过useCallback包裹后引用永久不变，不会随状态更新失效
• 块列表渲染时仅遍历docMeta.blockIds，每个Block组件仅通过自身的块id，从blockMap中读取对应的独立块数据：只有当该块自身的内容发生变更时，对应的块对象引用才会更新，其他块的引用始终保持不变
• 配合Block组件的memo对比逻辑，只要自身的块数据引用、传入的回调引用没有变化，哪怕全局其他块发生更新，当前块也不会触发重渲染
• 如果需要降低块组件的prop传递链路长度，可为单个块添加独立的状态订阅，让每个块仅在自身数据变更时才更新，完全不需要由Editor层统一传递所有块的props

方案兼容性说明 #

• 前后端数据结构完全对齐：docMeta对应后端documentModel、blockMap的每个条目对应后端blockModel，后续数据同步时无需做额外的结构转换
• 不影响协作功能实现：所有块状态都是全局可访问的，操作通过统一的dispatch链路流转，后续接入CRDT/OT类协作协议时，只需要将操作转换为同步消息格式即可，不需要调整核心状态结构
• 支持实时API更新：块内容的每一次变更都会触发独立的action，可通过中间件拦截块内容变更事件，直接发起对应块的API更新请求，不需要等待块失焦才同步

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