React useState通过map更新状态的合法性判断与性能对比

前置参考示例 #

我们先来看一个状态更新示例：

const initialState = [
    {id: 1, country: 'Austria'},
    {id: 2, country: 'Belgium'},
    {id: 3, country: 'Canada'},
  ];

  const [data, setData] = useState(initialState);

  const updateState = () => {
    setData(prevState => {
      const newState = prevState.map(obj => {
        if (obj.id === 2) {
          return {...obj, country: 'Denmark'};
        }

        return obj;
      });

      return newState;
    });
  };

问题1：以下写法一是否合法有效？ #

const updateState = () => {
    const newState = data.map(obj => {
      if (obj.id === 2) {
        return {...obj, country: 'Denmark'};
      }
      return obj;
    });

    setData(newState);
  };

简单同步场景下能得到正确结果，但存在稳定性风险，不是稳妥的合法写法。
如果这个更新函数是直接绑定在用户点击事件上、没有异步包裹、也不会短时间连续触发，外层拿到的data是当前渲染周期的最新值，且map逻辑做了不可变处理，更新结果是对的。但如果更新逻辑被包裹在setTimeout、Promise回调等闭包场景中，或者短时间内连续多次触发状态更新，这里捕获的data很可能是旧的状态快照，会直接覆盖之前的更新结果，出问题很难排查。 #

问题2：以下写法二是否合法有效？ #

const updateState = () => {
    setData(prevState => {
      const newState = prevState.map(obj => {
        if (obj.id === 2) {
          let newObj = obj;
              newObj.country = 'Denmark'
          return newObj;
        }

        return obj;
      });

      return newState;
    });
  };

完全不合法，是错误写法。
这里let newObj = obj是引用赋值，根本没有创建新对象，后续修改newObj.country本质是直接篡改原状态对象的属性，违反了React状态不可变的核心原则。React依赖状态的引用变化判断是否需要触发重渲染，直接修改原对象属性会导致引用不变，React无法检测到状态变化，大概率出现组件不更新的问题，后续如果用React.memo、shouldComponentUpdate做性能优化，这类写法会直接导致逻辑bug。 #

问题3：几种写法是否存在性能影响？哪种是最优实现？ #

三个写法的数组遍历开销完全一致，都是全量map遍历数组：

• 写法二看似省了对象展开的浅拷贝开销，性能略高，但本身是错误写法，会导致渲染异常，没有讨论性能的意义。
• 写法一的对象浅拷贝开销和参考示例完全一致，但存在闭包旧值的风险，一旦出现更新覆盖，反而会引发额外的异常重渲染或者逻辑错误，维护成本很高。
• 最开头给出的参考写法是最优实现：一方面用函数式更新接收prevState参数，保证任何调用场景下都能拿到最新的前序状态，彻底避免闭包陷阱；另一方面用展开运算符做对象浅拷贝，严格遵循不可变原则，React和周边生态的浅比较逻辑可以高效识别状态变化，既不会漏渲染也不会触发多余重渲染，是官方推荐的标准实现方式。

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