深入解析Ant Design Pro Components中columnsState持久化问题

问题背景

在使用Ant Design Pro Components的ProTable组件时，开发者经常需要处理表格列的显示状态管理。组件提供了columnsState属性来实现列状态的持久化存储，包括列的显示/隐藏、顺序、宽度等配置。然而，在实际使用中，开发者发现了一个常见问题：当同时配置了defaultValue和持久化参数时，页面刷新后列状态会意外重置为defaultValue，而不是从持久化存储中恢复。

问题现象

具体表现为：当ProTable配置如下时：

columnsState={{
  defaultValue: columnsStateMap,
  persistenceKey: 'node-table',
  persistenceType: 'localStorage'
}}

开发者期望的行为是：

1. 首次加载时使用defaultValue作为初始值
2. 用户调整列状态后，状态应保存到localStorage
3. 页面刷新后应从localStorage恢复用户最后的状态

但实际行为却是：

1. 首次加载使用defaultValue
2. 用户调整可以保存到localStorage
3. 但页面刷新后仍然使用defaultValue，忽略了localStorage中的状态

技术原理分析

ProTable的列状态管理核心逻辑基于以下机制：

1. 状态初始化：组件mount时会初始化列状态
2. 持久化层：当配置了persistenceKey和persistenceType时，会尝试从指定存储(localStorage/sessionStorage)读取之前保存的状态
3. 默认值处理：defaultValue提供了初始状态值

问题的根源在于状态初始化时的优先级处理不当。理想情况下，持久化存储的状态应具有最高优先级，其次是defaultValue。但当前实现中，defaultValue会覆盖从持久化存储读取的状态。

解决方案

临时解决方案

1. 移除defaultValue：如果不配置defaultValue，组件会完全依赖持久化存储

   columnsState={{
     persistenceKey: 'node-table',
     persistenceType: 'localStorage'
   }}
   

   但这样会导致首次加载时没有默认列状态

2. 手动初始化持久化存储：在组件渲染前预先写入默认值

   // 在组件外或useEffect中
   if (!localStorage.getItem('node-table')) {
     localStorage.setItem('node-table', JSON.stringify(columnsStateMap));
   }
   

   这种方法虽然有效，但不够优雅

推荐解决方案

等待官方修复的同时，可以封装一个高阶组件或自定义hook来处理状态初始化：

function usePersistentColumnsState(defaultValue, persistenceKey) {
  const [state, setState] = useState(() => {
    const saved = localStorage.getItem(persistenceKey);
    return saved ? JSON.parse(saved) : defaultValue;
  });

  useEffect(() => {
    localStorage.setItem(persistenceKey, JSON.stringify(state));
  }, [state, persistenceKey]);

  return [state, setState];
}

// 使用示例
const [columnsState, setColumnsState] = usePersistentColumnsState(columnsStateMap, 'node-table');

最佳实践建议

1. 状态初始化策略：明确状态恢复的优先级 - 持久化存储 > defaultValue
2. 默认值处理：仅在持久化存储不存在时使用defaultValue
3. 版本兼容性：考虑添加版本标识，便于未来数据结构变更时的迁移
4. 错误处理：对持久化存储的读写操作添加try-catch，避免解析失败导致页面崩溃

总结

Ant Design Pro Components的列状态持久化是一个强大但需要谨慎使用的功能。理解其内部工作机制有助于开发者更好地处理这类边界情况。目前可以通过自定义封装来解决问题，期待官方在未来版本中优化这一行为，提供更直观的状态恢复逻辑。对于关键业务场景，建议实现自己的状态管理层，以获得更精细的控制能力。