React中Table组件从props派生排序状态是否为合理用法？

你当前从props派生sortedRows到state的实现确实存在可复现的缺陷，具体问题点如下：

• 同步逻辑依赖生命周期，容易出现漏判或冗余计算。React 15.4版本下你只能在componentWillReceiveProps中监听props.rows变化触发状态更新，这个生命周期的触发时机仅和父组件重渲染绑定：如果父组件重渲染时传入的rows没有任何变化，你不做额外判断就执行排序+setState会产生无意义的性能开销，甚至触发额外重渲染；如果靠判断rows引用是否变化来决定是否更新，一旦父组件修改行数据时没有生成新的数组引用（比如直接对原数组做push、splice操作），内部排序状态就不会同步，直接出现展示数据和源数据不一致的bug。
• 浅拷贝+原地排序的逻辑存在源数据污染风险。你对props.rows做的浅拷贝仅复制了数组本身，数组内存储的行对象仍然和父组件传入的源对象引用一致，如果后续排序逻辑迭代时不小心在排序过程中修改了行对象属性，会直接修改父组件维护的源数据，这类跨组件隐式修改的bug排查成本极高。
• 状态同步逻辑分散，维护成本高。当前排序结果的更新触发点有两个：用户点击表头触发的sort方法、props.rows变化的生命周期回调，两处都要维护相同的排序逻辑，后续如果调整排序规则（比如新增多列排序、自定义排序函数），很容易出现一处修改另一处遗漏的问题，导致交互异常。

不需要升级React版本、不需要引入任何第三方依赖，只要调整state存储的内容，就可以完全避开派生状态的反模式，同时满足你所有的业务需求：
核心思路是不要把排序后的衍生结果存在state里，只把排序交互产生的可变规则存在state中，排序结果在render阶段实时计算即可，具体实现步骤：

1. 调整组件内部state结构，仅存储和用户交互相关的排序规则，不存储任何从props派生的行数据：
   • sortKey：当前激活排序的字段，默认值可设为初始排序字段或null（代表不排序）
   • sortOrder：排序方向，可选值为升序asc/降序desc，匹配初始排序需求
2. 实现10行以内的简易缓存逻辑，避免每次render都重复排序：在组件实例上挂载缓存对象，存储上一次计算时用到的rows引用、sortKey、sortOrder和对应的排序结果，每次计算前先比对三个依赖参数是否和缓存一致，一致则直接返回缓存结果，不一致再重新计算排序。
3. 表头点击的交互回调只需要更新state里的sortKey、sortOrder即可，不需要手动操作排序结果。
4. 完全移除componentWillReceiveProps里所有和rows同步相关的逻辑，不管props.rows什么时候更新，render阶段都会自动读取最新的rows结合当前排序规则计算结果，从根源上避免状态不同步的问题。

核心实现代码参考：

class Table extends React.Component {
  constructor(props) {
    super(props);
    // 仅存储交互相关的排序规则，不存派生数据
    this.state = {
      sortKey: props.defaultSortKey || null,
      sortOrder: props.defaultSortOrder || 'asc'
    };
    // 排序结果缓存，无需引入第三方库
    this.sortedCache = {
      lastRows: null,
      lastSortKey: null,
      lastSortOrder: null,
      result: []
    };
  }

  // 表头点击回调
  handleHeaderClick = (key) => {
    this.setState(prevState => {
      // 同列点击切换排序方向，不同列重置为升序
      if (prevState.sortKey === key) {
        return { sortOrder: prevState.sortOrder === 'asc' ? 'desc' : 'asc' };
      }
      return { sortKey: key, sortOrder: 'asc' };
    });
  }

  // 获取排序后行数据
  getSortedRows = () => {
    const { rows } = this.props;
    const { sortKey, sortOrder } = this.state;
    const cache = this.sortedCache;

    // 缓存命中直接返回结果，无额外计算开销
    if (
      rows === cache.lastRows &&
      sortKey === cache.lastSortKey &&
      sortOrder === cache.lastSortOrder
    ) {
      return cache.result;
    }

    // 缓存未命中，重新计算
    const copiedRows = [...rows];
    if (sortKey) {
      copiedRows.sort((a, b) => {
        const valA = a[sortKey];
        const valB = b[sortKey];
        // 可根据业务扩展字符串、数字等不同类型的排序逻辑
        return sortOrder === 'asc' ? valA - valB : valB - valA;
      });
    }

    // 更新缓存
    cache.lastRows = rows;
    cache.lastSortKey = sortKey;
    cache.lastSortOrder = sortOrder;
    cache.result = copiedRows;
    return copiedRows;
  }

  render() {
    const sortedRows = this.getSortedRows();
    // 后续表格渲染、无限滚动逻辑都直接使用sortedRows即可
    return (
      {/* 渲染逻辑略 */}
    );
  }
}

这个方案的优势非常明确：

• 完全符合React单向数据流原则，props.rows始终是唯一可信数据源，没有任何分散的状态同步逻辑，从根源上避免派生状态带来的不同步bug
• 不需要父组件传入任何排序相关的回调或处理排序逻辑，所有排序能力完全内置在Table组件内，父组件只需要传入rows即可，复用成本极低
• 不会因为props变化触发组件销毁重建，无限滚动的位置、加载状态都会完整保留，用户体验不受影响
• 自带的缓存逻辑性能和你之前把sortedRows存在state里的方案完全一致，甚至更优——因为不需要在props变化时额外触发一次setState导致的二次重渲染

注意：不要担心在render阶段做计算会有性能问题，React本身就推荐将和渲染相关的纯计算逻辑放在render阶段执行，只要配合合理的缓存，性能远好于在各个生命周期中分散同步状态的实现。

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